Should the W3C and WHATWG Die?

[felgall]

@mawburn

Don’t mistake the choices of the browser/engine developers for those of the w3c.

Why not - they are basically the same people.

Where all of the browsers interpret something in the standard a particular way then that was the way they intended it to be interpreted when they added it into their standard.

The W3C standards are written by browser developers for browser developers.

[PaulOB]

@jeffreylees

But yeah. So, swinging back to the major issue here… are you against adding to the specification in this or any other case for ease of use, basically, or are you just arguing this single case?

I was basically just confirming Ryan’s point about vertical-align specifically as he mentioned me in his post.

However, I do agree with some points in the article that some parts of CSS are not intuitive and have taken too long to evolve (although now they are moving quite quickly). I also believe that some things have been made unnecessary complex (such as flexbox) when maybe simpler methods would have sufficed.

[vote539]

The W3C’s job isn’t to design the syntactically greatest markup language. Their job is to issue specifications for capable and interoperable markup languages.

In many ways, the W3C’s HTML/CSS is a lot like a human-readable JVM. There are many languages that compile to HTML/CSS (HAML, Jade, ERB, SASS, LESS, Stylus), just as there are many language that compile to the JVM (Java, Scala, Clojure, JRuby). Both W3C HTML/CSS and the JVM are interoperable over many platforms, which is a driving reason that developers use them. But developers on both platforms can choose a language of their choice, knowing that it will ultimately be compiled down to a fully interoperable form.

If anything, the W3C should focus on designing a standard that reduces bandwidth consumption (some sort of “binary CSS”). But for the time being, the thing that’s going to make developer’s lives easiest is for the W3C to stay on its current track.

[louislazaris]

@molona

So if I have to create a full layout with tables with CSS properties… then why shouldn’t I use a full HTML table instead? Because I still need to think about screen readers, bots, etc.

Hmmm, that’s interesting because I was under the impression that CSS would not affect the accessibility of the elements. But…

Using display:table has semantic effects in some screen readers

Maybe @PaulOB can chime in here… Is that post from Roger still valid in modern browsers and newer screen readers? Because if that’s the case, then the point of Dimitrii in his original article (first one linked in the OP) is valid, and thus using CSS tables for vertical alignment with unknown heights is probably not recommended.

[ralphm]

Ugh. I had no idea screen readers took so much notice of CSS like that. That they recognise display: none on an element is really handy, but otherwise, I had assumed they mostly just read through the HTML—as they should, IMHO.

It would be interesting to hear from @Stomme_poes on this as well (our resident accessibility super cat).

[PaulOB]

@ralphm

It would be interesting to hear from @Stomme_poes on this as well (our resident accessibility super cat).

Yes it would be interesting to hear what Mallory has to say on the subject as I have no details on this but from a CSS perspective it has always been the case that CSS imparts no semantics on the html. Otherwise every time you used display:inline on an element your code would likely be non-semantic.

The fact that some screen readers decide to apply structure to a page because of the css is clearly some sort of bug. The CSS table model has never been a way to display table data because that’s what an html table is for. It’s just another layout mode.

Display:table is just another display property so that the visual appearance of a layout can be changed and assistive technologies should not really be concerned with this. It should not be a case of having to second guess everything,

[StevieD]

@felgall

Anyway, an attempt was made to start over with designing HTML - it was called XHTML 2.0 and had lots of streamlining of tags compared to the existing ones - eg. tags with the level being determined by the nesting rather than a number in the tag name and being able to make anything a link by including an href attribute in any tag - so that the <a> tag no longer existed. That effort was eventually abandoned because too many pages have been written following the current messy standard and most people don’t want change.

The main reasons that XHTML2 disappeared into oblivion were:
1 - most people don’t understand XHTML and can’t cope with the strictness of it (hence the huge number of pages written in fauXHTML), and
2 - the changes they made to the specs, including the switch to a single heading level to be determined by page structure and the removal of the <a> tag, made lifemore difficult for developers than HTML4.

[molona]

@louislazaris

Hmmm, that’s interesting because I was under the impression that CSS would not affect the accessibility of the elements. But…

As far as I know, it doesn’t care much but yeah, Mallory (@stomme_poes) is the expert about accessibility.

I confess that I’m aware that I should pay more attention to accessibility. It is a topic that I care about. But, as with many, the lack of time doesn’t allow me to gain more knowledge about it.

My point was that the only advatange of using CSS tables (so to call) was that I could use more semantic HTML but, if I have to build a whole HTML (anonymous or not) then, well, that’s the only advatange I can see…

[Stomme_poes]

@paul

from a CSS perspective it has always been the case that CSS imparts no semantics on the html.

However HTML semantics are not the only thing sent to the AT layer via the browser. The browser builds the tree, and it sometimes uses display settings to determine what will be included. This is why display: none affects screen readers-- the browser states “this is not displayed”, and does not add it to the rendered tree. Conversely, and listen up, CSS-generated content is starting to get sent to AT-- VoiceOver on Safari has been reading it for a while. But, not content like what comes from using CSS counters… It depends a lot on the browser, IE for example doesn’t (or wasn’t) put generated content into the tree, Firefox sometimes does, Safari does.

Roger’s article’s a bit old, though I should check in Orca to see how it’s doing (with a new Firefox it shouldn’t report tables…).

[Lucanos]

I would kill for these standards groups to, well, enforce standards. For example:
Why, in 2015, do we still need to use CSS Resets to level the playing field before writing predictable CSS?
Why, with all the progress made by jQuery, and it’s standardised syntax across all browsers, are they not looking at tightening up the Javascript standards? Maybe even including jQuery as a module to the core?

We’ve come a long way, I know, but we’re still needing to use hacks to make simple, common things work? The modern hacks are fewer, and more elegant, I grant you, but an elegant hack is still a hack.

[RyanReese]

@Lucanos

I would kill for these standards groups to, well, enforce standards. For example:

It’s not like hte standards are “laws” of the web. They are just recommendations.

@Lucanos

Why, in 2015, do we still need to use CSS Resets to level the playing field before writing predictable CSS?

To give some sort of style to the webpage even if there is no CSS. Each browser has slightly different CSS files. That’s acceptable.

[quote=“Lucanos, post:53, topic:110806”]
Why, with all the progress made by jQuery, and it’s standardised syntax across all browsers, are they not looking at tightening up the Javascript standards? Maybe even including jQuery as a module to the core?
[/quote]Dunno JS that well so I’ll leave this be.

[molona]

@RyanReese

It’s not like hte standards are “laws” of the web. They are just recommendations.

You’re righ. Browser vendors do not need to implement the standard if they don’t want to. It is funny and ironic that they participate in the creation of these starndards… so one would think that they would agree in their implementation.

Microsoft has been famous for proposing something… and then do exactly the contrary in their own browser, as an example

[ralphm]

@Lucanos

Why, in 2015, do we still need to use CSS Resets

You don’t need to. Many argue that they are a bad idea anyway. Just style elements as needed and you’re fine.

@Lucanos

Why, with all the progress made by jQuery, and it’s standardised syntax across all browsers, are they not looking at tightening up the Javascript standards?

I don’t think it’s their job to try to accommodate the failings of browsers. That would just make browser vendors lazier. Fortunately, browser makers have upped their game of late, which is the better scenario.

[felgall]

@Lucanos

are they not looking at tightening up the Javascript standards

This is already happening. IE have now abandoned their own proprietary commands as of IE8/9 and from 9/10 onward accept the standard JavaScript commands.This means that there is far less cross browser differences that need to be handled.

JQuery 2 is much smaller than JQuery 1 because all of the cross browser support for IE8 and earlier was removed.

With many of the JQuery commands having native JavaScript equivalents having been added since 2011 and with more such commands still to come JQuery itself should completely disappear within a few more years as everything it was designed to to will then be able to be done using equivalent native JavaScript commands without needing all of the JQuery code to convert it into old style JavaScript that long dead browsers can understand.

[ralphm]

Although, frameworks aren’t just for ironing out browser bugs, but for providing pre-written code to do common (and possibly difficult) tasks. I’m no fan of frameworks, but that’s an understandable reason to use one.

[felgall]

@ralphm

for providing pre-written code to do common (and possibly difficult) tasks

Many of the commands in JQuery that used to require significant amounts of JavaScript to do now have corresponding native JavaScript commands to do exactly the same thing. The way things are going, in a few more years all that any JQuery command will do is call the native JavaScript equivalent command.

[jeffreylees]

@RyanReese

It’s not like hte standards are “laws” of the web. They are just recommendations.

[Stomme_poes]

Why, in 2015, do we still need to use CSS Resets to level the playing field before writing predictable CSS?

I don’t. CSS resets are like using Bootstrap – it’s easier for some people who want something done quickly that mostly looks okay in all the versions of Chrome and Chrome-imitators. : P

Maybe even including jQuery as a module to the core?

Ug. Quick, someone get to a liposuction clinic and get me a bag of fat to attach to my body! I still fit in an airplane seat!
Honestly, jQuery would have to meet standards better itself before it could be considered (though in fact some of the standards-writers have floated this idea of putting jQuery natively in browsers). They could rename their named-by-monsters “grep” function (it doesn’t grep, it filters), they could implement real A+ promises (though maybe by now they already have, but they didn’t in the version we’re using, which yes is under 2 because all our clients and their clients use IE).
Real native Javascript however is finally getting the functional tools it should have had long ago: immutables, real Map/Filter/Reduce, Set types, Map types, object.observe etc.

Screw jQuery DOM manipulation, I want real functionality like the above. I’ll be cursing the users of ancient browsers only supporting ES5 longer than I’ll be pining for some sort of native Dom-manip library, plus as felgall said, vanilla is catching up there (again, not for folks like me, who can’t use nice stuff like getElementsByClassName or classList or whatever due to… clients and their clients).

We’ve come a long way, I know, but we’re still needing to use hacks to make simple, common things work? The modern hacks are fewer, and more elegant, I grant you, but an elegant hack is still a hack.

Agreed, and whenever I see dirty hacks to make basic things work (accessibility-wise), it pisses me off. Like, right now, they’re discussing (modal) dialog boxes on WebAIM. Like, if it’s formy-enough, it should work like a role=application but if it’s more documenty then role=document? And manually trapping keyboard and manually setting focus? That’s all crap, hacky, turns developers off and makes Doing the Right Thing way harder than it should be, to the detriment of users.

But for me it’s not basic CSS and JS. It’s bullcrap like certain vendors making devs dance and sing, backwards and in high heels, just to avoid implementing Microsoft’s freaking awesome Pointer Events.

Seriously we should all be screaming at Apple (and others) to implement this. Holy crap no more listening for 500 freaking mousey touchy pen/stylus/finger/swipe/wtf events Batman!