A week with the www-style mailing list
The W3C communicate using mailing lists (you may need to look up what one of those is). I decided to take my CSS thoughts direct to the people that actually write the CSS Specifications by joining the list and posting a few thoughts. Here’s what I covered in the first week:
CSS is not capable of supporting aspect-ratio’s for elements
The gist here was that <img>’s scale proportionally with max-width. <div>’s etc do not, and they need to sometimes. It turned out this had been discussed before and conversation continued on the older thread ”aspect-ratio property”. My belief was that a new aspect-ratio property seems confusing and un-necessary as aspect ratio is expressed as a ratio between height and width. I proposed to have CSS be capable of referencing one of the current elements properties (so we could write width: calc(height/2);) - this turns out to be unworkable, as Tab Atkins explained:
This is problematic due to implicit dependencies. If the width depends on the height (for example, if this was in a vertical text writing-mode), then you’ve got a problem - you can’t calculate the width until you know the height, but you can’t calculate the height until you know the width.
Additional details on how CSS would have issues with this were explained, again by Tab.
Update: To clarify - as I didn’t mention originally - there is a solution to the issue of aspect ratio’s in the form of the proposed aspect-ratio property (which I can not find a URL to link to)
We can’t centre vertically if we don’t know the height of the box and container
Here I questioned why vertical-align:middle; only works on elements that have a display type of table, when it would be just as useful in other display types, like block. Tab once again explained that this is a much harder problem than it first appears, and mistakes were made long ago that can’t be corrected now without breaking existing sites.
CSS’s existing layout algorithms are biased towards blocks that fill their containers horizontally and stack vertically. In this model, horizontal centering is easy (just put the free space on either side), but vertical centering is hard (what do you do if one element wants to be centered but the next doesn’t?)
As you note, tables get around this by having the *container* declare that its contents will all be centered. We could potentially have had other elements do this as well, but due to a historical accident, we didn’t, and we can’t change it now (because doing so would damage page layouts that depend on the current behavior).
Abspos centering is a completely different matter. This is purely a historical accident - you can already horizontally center an abspos by giving it “left:0; right:0; margin: 0 auto;”, and there’s no reason it shouldn’t work exactly the same vertically except that it was defined incorrectly early on. Again, it’s been this way long enough that we can’t fix it now.
Update: It was pointed out that new layout modules can solve the vertical-align problem.
% is not a valid unit for border-width
It was generally agreed that this doesn’t make much sense and it would be nice to get % as a valid unit on this attribute. L. David Baron, of Mozilla, stepped in and explained why browsers will find this difficult:
… if we want to introduce percentages to borders in a way that will produce expected results in fluid designs, we’d need (unless there’s a solution that I’m not aware of) to sacrifice something else: either consistency of border widths (i.e., different sides of a box with the same specified border width will have borders occupying different numbers of pixels) or things-adding-to-100% (which isn’t much good for fluid designs).
So I’m a little skeptical, and I think if we do this we should probably think about specifying rounding and pixel-snapping behavior in CSS (given how much Web sites depend on it).
My personal take is that the uneven border width issue is a current problem that will go away. The only reason it’s uneven is because of the limited number of pixels on a screen. As screen continue to get higher and higher DPI those borders will become more and more even, making this a current technology problem, and not a genuine language or feature problem.
A use-case for having % border widths was asked for, so I supplied the Adaptive Images design - the gallery images and layout all scale in proportion. It is impossible for me to add borders onto the images and retain this behaviour. It was agreed this is a valid use case. No further action has taken place, the thread is dead.
Update: Tab has pointed out that this spec has no editor at the moment, which is why it appears to have gone nowhere.
CSS Referencing
The idea is best illustrated with pseudo-code:
div.thisdiv { height: (div.otherdiv); }
div.otherdiv { height: (div.thisdiv); }The ability to use a selector to reference a different element’s property would allow styling to become independent of HTML order, as follows:
div { position: (h1); top: 10px; left: 10px; }Although the first use cases were argued against it turns out that the later one (positioning an element relative to any specified other element) has been proposed by Tab - it’s just being stone-walled by the Positioning editor who doesn’t feel it’s necessary.
Update: Tab is still talking with Aaron about this issue, it is ongoing and not “stonewalled” as I had understood.
Forums
I asked the question of why something as important as the W3C is still using mailing-lists as the main method of communication, when the majority of today’s web developers will never have used one, and when purpose-built solutions to the “group communication” problem now exist. See the thread for the gritty details, but the result is that the W3C are never going to move away from mailing lists, even if they did there are a significant group of core members that would refuse to use forums (and a fair few that refuse to use non-plaintext email even).
I tried to get some agreement or consensus on how to fix the public-facing issue the list has - lack of easy discovery, lack of clear explanation of what it is, how it works, how to contribute, and terrible user experience (you’ll note that all of the links in this article go to a web-page that displays a single email from the thread. Usability and ease of discovery are two nightmare elements of the W3C List i take big issue with). It was agreed readily that there is an issue with how non-members can (or can’t) find the lists, or browse it’s content effectively. Unfortunately, it’s going to be hard to change those aspects. In order to make the online archives W3C uses software that hasn’t seen an update in many years, and no-one seems both capable and willing to resurrect it in order to improve it. Because the entire list is email instead of a database, there’s no way to simply install some off-the-shelf software to convert it from email to web-based media. The irony that the W3C steadfastly refuse to use native web technologies to build new web technologies strikes me dumb. I guess there isn’t a belief in “eat your own dogfood”.
The topic has effectively stalled, it seems highly likely that no change will occur.
Update: To be clear, this is not due to a lack of will, but a lack of resources. If you can help, please do!
Orphan control in CSS
An orphan is a singular word that drops to a new-line at the end of a sentence. They’re a typographic no-no and never happen in professional print. I’d like to have something like:
h2 { orphans: 2; }which would control the minimum number of words that must be dropped onto a new-line if a new-line is required.
This turns out to be a much harder problem than anticipated due to knock-on issues. The way type is laid out in CSS needs a radical overhaul in order for things like orphan control or decent text-align:justify; to become workable. See the discussion for the detail on these issues. The discussion showed that CSS’s very limited type layout engine has been considered before, but this thread is another example of a topic seeming to have petered out without actually going anywhere or effecting any change or further discussion on the core issues.
Update: This module is not being actively developed at the moment, which is why it appears inactive now.
Blending Modes as part of the Color Module
Blending modes are being talked about and included in the Image module. I proposed that they would be far more useful in the color module. I got one response and the topic has sunk. My proposal can be read on my blog.
A CSS equivalent of HTML’s DOCTYPE trigger
Given that already a couple of replies to issues above had indicated that there are poor implementations of existing specs (or simply badly defined specs, such as the vertical-align issue) I proposed we implement some sort of switching mechanism, so we can fix broken and poorly implemented specifications without breaking backward compatibility for current sites. This would allow revisions to existing properties and let the author pick which version he’s writing for (assuming if no trigger is given it’s the first version). This idea was effectively shot down, and to be honest I do not understand why. Support for the idea seemed good, then the thread died.
Update: Tab has clarified his thoughts on this in the comments below.
Adding a font to the current stack
Evolved into an interesting discussion on the internal mechanics of CSS. It seems that it’s not just font stack that has this issue, but that it’d be useful to specify a behaviour for CSS that translates as “try this rule, but if the resource fails to load then just use what you would have done if I’d never written this rule”.
Update: To clarify - this topic is ongoing and quite an interesting problem.
Conclusions from one week of contributions
- CSS is much harder to work with technically than it is to use as a web developer.
- The communication structure the W3C use is opaque, clumsy, and for a reasonable percentage of it’s users; barely fit for purpose. Nothing is documented anywhere such that a person new to the process could learn how the system works, peculiar etiquette (like quoting the entire thread in all mail replies), and where to put ideas in order for people with power to notice them.
- A fair few great people are working very hard at addressing a lot of issues. Big respect for all involved.
- And yet the list seems to be a place where conversations go to die, never having made any real change. This is not necessarily the case, just how it can appear
- Most people involved know there’s a communication problem. Resources are not available to be put in to deal with that, and many members don’t see the significance of the problem.
A plea for help
So, there’s a taster of what it’s like. Please, please, help. If you have skills or time to put in, join the list and help. It’s not for lack of good will or effort that things are like this over there - there’s a lack of people with the right skills and enough time. In particular I think we could greatly benefit from someone capable of updating the ancient HyperMail software in order to improve the public facing archives. We could also do with people with experience in the nitty-gritty details of type layout joining in. Heck, if there are software engineers who implemented some of InDesign’s text engine they would have so much to contribute to getting decent typography on the web.
Talking on blogs is good. But unless your voice is heard by the people involved in making the standards we all use, your blog is ineffective. So, take it to the list. And if, like me, you find the list isn’t as effective as you’d hope - help change that.
Entry Information
- Posted:
- Sun, 15th Jan 2012 at 11:01 UTC
- Filed under:
- Tags:
Comments
skip to comment formMan, your summary makes it sound like every single issue was a failure. That's not true, though!
For aspect-ratio and vertical-centering, I also explained how it *will* be possible in the future (the 'aspect-ratio' property and Flexbox or Positioning, respectively).
For %ages in border-width, you got as far as is reasonable right now, since there isn't an active editor on Backgrounds&Borders 4 yet. Don't worry, it'll see some action when one of us has time to work on it.
For positioning-by-reference, I'm not being "stonewalled" - me and Arron are still discussing the issue.
For Forums, the conclusion was that someone who cared about the issue had to spend the time to get something going. Most of us in the group *are* happy enough with the status quo, but "patches welcome", so to speak.
Orphan control is in the same boat as %age border-widths - it would likely go into Text 4, which isn't being actively developed yet (the editor is attempting to get Text 3 finished now). When she's ready to seriously look at the issue, she will.
The Blending Modes topic did kinda die. I know there are performance issues in here that require you to get things *just* right, and it's not at all obvious what the right things are. As we align more with SVG we'll have some more discussion on blending, though.
For the "CSS doctype switch", I thought I explained the reasoning why I considered it a bad idea - versioning the language is something that shouldn't be done casually; it should only be done when there's no other alternative and the core language has simply grown too crufty for more patches to be reasonable. I don't think CSS is at that level.
The font-stack issue was indeed interesting. Chris Eppstein (from SASS) contacted me privately on that topic as well, discussing how SASS is adding functions for manipulating list-valued properties. I continue to see confusion abound, though, with people accidentally talking about manipulating inherited values (which is relatively easy) rather than manipulating "a less specific version of this rule in the cascade". However, the fact that this can be "fixed" in some cases with Variables is pretty interesting, I think. I have a followup thread I need to post on the issue.
All in all, you had a *really successful* run. About half of the issues you raised were successfully addressed (either by pointing out existing work being done, or by adding useful fodder for future specs that aren't yet being worked on). About a quarter were shot down as probably bad ideas, and the remaining quarter were non-committal, because they need more work from interested parties before we can really think about it.
Thanks so much for all of that!
Oh, and a parting shot - for obvious reasons, a lot of the visible "holes" in CSS that designers often complain about are precisely the things that are hard to address (or else we would have already plugged them!).
Unfortunately, this means that for many people it appears that all of their ideas get shot down any time they raise them, which gives the impression that the CSS Working Group isn't interested in new ideas. ;_; Nothing could be further from the truth! These issues are just *really hard* technically, and it's often not obvious *why* they're hard unless you've got intimate experience with a browser's guts.
Another unfortunate reality is that there's only a handful of active editors in the WG - our membership roster is fairly large, but most of them only contribute via the mailing list, or on specific topics they're interested in. There's only a half-dozen or so of us that actually do most of the writing and have general interest in CSS as a whole. This means that even when somebody avoids the hard problems and suggests something new and good, we often don't have the time to develop it immediately. Instead, we'll file it away as "something to look at when I'm done with what I'm currently doing", which is often several months away.
For example, I'm currently working on three specs (Images, Lists, and Flexbox), with a finger in a few other topics (Variables, Grid, Positioning, Hierarchies, Aspect-Ratio). I'm pretty much full-up on work right now as a result; even if I'm not actively writing text for any of my specs, I'm still dealing with feedback, or importantly, waiting for others to give sufficient feedback that I feel like my specs have received enough attention.
That brings us to the final unfortunate reality - because there's a relatively small number of people with sufficient knowledge and interest to *really* dive into a spec and give it a review, specs *by necessity* have to move somewhat slowly. All three of my active specs were "finished" months ago, but they're in review stages now. As people implement them or have time to review them between all the other things they do, I'll refine the spec until I feel it's ready. Luckily, all of my current specs are nearly there - Images just entered Last Call stage, Flexbox will be in Last Call in a month or two I expect, and Lists just needs review of some of the positioning parts before it's ready as well.
So, even in the best of circumstances, a lot of ideas won't trigger immediate action as they'll run into one of the above. Even we WG members get most of our ideas shot down this way - the major difference is that we're committed to the group, so it's easier for us to be persistent when the failure-point is just "no one has enough time right now" or something.
Still, though, it is so *so* valuable when designers send in their feedback and ideas. If the idea gets shot down, it's still a signal that this is a topic that people care about, so it's more likely to be seriously dealt with in the future. A good fraction of the time, though, your feedback *does* have noticeable effects in a reasonable time-frame - take, for example, the feedback about "magic corners" in linear gradients . Behnam suggested it in July, and by late August (after a lot of technical back-and-forth between me and some interested implementors) it had made it into the Images spec.
So please, keep sending stuff in! Woo!
Hey Tab
Sorry - it does come off bad - it wasn't my intent to have it sound like everything gets shot down! I meant the post to illustrate that it's fairly obvious that more hands with the right knowledge are needed, which is why I wrote the latter section of the post asking for more hands on deck.
It's commendable (and pleasing) that almost all the feedback I got from the group was well written, well considered, and well explained - even when my own communication was not entirely up to that standard. Where I didn't quite understand things it was entirely down to my unfamiliarity with some concepts, system, or terminology.
One additional thing I'd like to make clear *is* a potential problem is the way that threads can trail off without someone explaining that the matter has been flagged and will be looked into further. Because without that, it does feel as though things just end without any resolution. Feedback of that sort would be great.
Not giving "resolution feedback" is the kind of mistake we used to make at work years ago, and clients always get jumpy when that happens. Simply stating what's been done and what will happen next helps our client relations no end, and I think it'd help in www-style too.
Yeah, I agree. We're gradually evolving better, more visible ways to track feedback, like using bugzilla for more issues, etc. We should be better about using the wiki's Ideas page to log things that are interesting but haven't yet got a place to live, too.
You didn't mention where you find www-style, but I would like to point out two things about your posts and participation:
1. All the issues you mentioned above are all raised by you.
I would suggest you include your experience with the "[css4-ui]/[css4-selectors] Pseudo-class for selecting broken images & other external resources" thread here too. You might want to get more involved with the community by replying more mails and saying support to features raised by others.
2. You don't put [css3-*] [css4-*] in your subject line
I think most people who come to www-style because they see somthing like
[[
Discussion:
www-style@w3.org with subject line g[css3-text] c message topic ch
]]
in a CSS spec[1], and this is a discussion forum centered around specs and not necessary a request channel for browser features. For the latter purpose, you might want to file feature requests to specific browsers too.
I disagree with the claim that "the majority of todayfs web developers will never have used one (mailing list)"[2], although I hope we don't discuss into this again.
I have my last question for you and perhaps Web developers in general: why are you more willing to go through the
have some features I really want in my daily life ¨ the spec doesn't have such a feature ¨ raise it on www-style
route instead of
have some cross-browser problem when I develop a Web site ¨ the spec doesn't say which browser is correct ¨ raise it on www-style
route? My personal experience tells me that you would feel less frustrated if you contribute this way. Furthermore, the faster browsers handle all the interoperability issues of not-so-new features the faster they can adopt new ones.
The page looks nice by the way.
[1] http://dev.w3.org/csswg/css3-text/
[2] http://lists.w3.org/Archives/Public/site-comments/2012Jan/0007
Great work Matt! Keep it up!
I just have to respond to:
"versioning the language is something that shouldn't be done casually; it should only be done when there's no other alternative and the core language has simply grown too crufty for more patches to be reasonable. I don't think CSS is at that level."
Everyone else versions languages - C, C++ Java, Perl, PHP, Javescript, ……
Maybe if we had provided a way of versioning CSS - not just the specs - from the *start* instead of opting for "graceful degradation" we wouldnt see so many questions answered with ~ "we cant do that because it would break exising stuff".
@Kang-Ho (Kenny) Lu
Thanks for the feedback and links
Good point about linking to the list, but where do I link to "www-style" considering it's a mailing list and not a web page? I've already linked to archived responses in the headings.
RE my participation: yes, the blog-post states at the top that it covers the topics I've raised over at www-style. If I don't comment too often in other threads it is because I don't feel I have enough to contribute in those other threads. I have commented where I feel I have something to add, and will continue to do so.
"You don't put [css3-*] [css4-*] in your subject line"
I had no idea I was supposed to. This is exactly one of those things I am trying to illustrait - there is no documentation or guide at all to how to contribute well to the list. No guide on formatting, or what to do, how the group works, etc. And, frankly, how am I supposed to know what topics are css3 and css4? Where is that covered? The entire W3C process is opaque. How, as a newcomer not already familiar with the W3C, are people supposed to find out the things which seem to be taken for granted by members of the lists?
Browser features are not something I have requested or raised, so I'm not sure what point you're making?
I'm leaving the debate on how many web developers are familiar with using mailing-lists for group communication (as opposed to bulk CCing), short of an online questionnaire no-one is going to accept the other person's view on this.
As for the last topic you bring up: because it's not an issue. I have a far larger and more important list of "stuff CSS should be doing but doesn't, why?" than I do "hey, FireFox got this right but Safari didn't". In fact, I can't think of a single instance in the last 6 months where one browser acted differently to another and caused a problem (excluding IE). Cross browser stuff is just not an issue in the real world day-to-day web, where as it might well be for people pushing into HTML5/CSS3's incomplete features - which responsible developers don't use on production web sites built for and paid for by clients. Which is what I'm doing. It's why I don't use HTML5's new tags - I am not willing to use JS to patch old browsers.
I don't want www-list to be just a "which browser did it right" list. I want it to be a "CSS is for designers, what do you designers need?" list too.
In reply to:
[[I had no idea I was supposed to. This is exactly one of those things I am trying to illustrait - there is no documentation or guide at all to how to contribute well to the list. No guide on formatting, or what to do, how the group works, etc.]]
I think www-style newcomers usually learn these with the following steps 1) follow the list 2) read some discussions 3) join some discussions 4) raise new discussion, although this is arguably taking long and your effort to document these would certainly be appreciated. One thing I would like to mention is that this process should just be very similar to, say, the jQuery development team.
In reply to:
[[And, frankly, how am I supposed to know what topics are css3 and css4? Where is that covered? ]]
You read parts of the spec relevant to your request and if your request is not yet in that targeted spec you raise it on www-style. The list to all the CSS specs is in [1]
[1] http://www.w3.org/Style/CSS/current-work
In reply to:
[[Browser features are not something I have requested or raised, so I'm not sure what point you're making?]]
You want your proposals to get implemented in browsers right? Or what else is the point in writing up your proposals in the specifications? I don't know if you have the notion that "browsers vendors", "spec editors" and "Web developers" are three groups of people. The reality is that spec editors are mostly associated with browser vendors because, as you mentioned, "CSS is much harder to work with technically than it is to use as a web developer".
In reply to:
[[Cross browser stuff is just not an issue in the real world day-to-day web, where as it might well be for people pushing into HTML5/CSS3's incomplete features - which responsible developers don't use on production web sites built for and paid for by clients. ]]
If you proposals are adopted, are you not going to care if these features work in different browsers?
In reply to:
[[In fact, I can't think of a single instance in the last 6 months where one browser acted differently to another and caused a problem (excluding IE).]]
Other Web developers do need to face these kinds of problems, especially if they are using new features in HTML5, and my guess is that this kind of input would be more acceptable to general www-style audience.
Is it me or did your little stint at least partially influence this A List Apart article? http://www.alistapart.com/articles/every-time-you-call-a-proprietary-feature-css3-a-kitten-dies/
The "How can I help" section includes some of the posting etiquette's of the www-style mailing list.