Tag: W3C

Categories
Personal

Position Statement for the 2022 W3C TAG Election

Reading Time: 3 minutes

Update: I got re-elected!! Thank you for trusting me once more with this huge responsibility towards the Open Web. I will continue to do my best to justify the confidence the W3C membership has placed in me. 🥹

Context: In 2020, I ran for the TAG election for the first time and had the great honor of being elected by the W3C membership. This year, I’m running for re-election. The W3C Technical Architecture Group (TAG) is the Working Group that ensures that Web Platform technologies are usable and follow consistent design principles, whether they are created inside or outside W3C. It advocates for the needs of everyone who uses the Web and everyone who works on the Web. If you work for a company that is a W3C Member, please consider encouraging your AC rep to vote for me! My candidate statement follows.

I’m Lea, and I’m running for re-election to the TAG to continue applying my usability research, CSS WG, and TAG experience to help W3C stay connected to the developer community, and to better serve their needs by ensuring web platform features are not only powerful, but also learnable and approachable, with a smooth ease-of-use to complexity curve.

I wear many hats. My background spans almost two decades of web design & development experience, one decade of standards work in the CSS WG, nearly a decade of PhD level human-computer interaction research & teaching at MIT, and over a decade of educating web developers through talks, books, articles, and helping them through my dozens of open source projects, some of which are used on millions of websites. For those unfamiliar with my background, I encourage taking a look at my 2020 candidate statement.

In 2020, I had the great honor of being elected to serve on the TAG by the W3C membership. In the two years I have served on the TAG, I participated in over 70 design reviews and helped prioritize API design in our reviewing. I have been publicly praised for the quality of design reviews I led. 

It is important that the TAG does not operate in a vacuum:  The primary purpose of our work is to serve developers and end-users by ensuring web platform features are usable, secure and privacy preserving. I have used my experience during design reviews to make sure we remain connected to this mission.

Together with Sangwhan Moon, I took the lead on our Web Platform Design Principles effort, which documents the principles that underlie Web Platform features — previously only existing in WG lore. The Web Platform is going through an explosion of new features; only in the last year the TAG received almost a hundred design review requests. With this volume, it is important that reviews are consistent, transparent, and fast. Evolving our published design principles helps with all three goals.

The Web ecosystem is not just the Web Platform itself, but also the various tools and libraries out there. I started a project to publish a subset of the design principles that apply to web developers, to help them in creating Web Platform compatible APIs. After all, with web components, web developers are now HTML designers, with Houdini APIs, they are now CSS designers, and with JS, they’ve been JS API designers since forever. The project is currently in its infancy, and If elected, it will be one of my tasks to get it published within my next term.

As a Greek woman, I bring both a Mediterranean and European perspective that diversifies the TAG and as a fully bilingual Greek and English speaker, I can fully participate in rapid technical discussions while also having an appreciation of the Internationalization needs of those who use the Web in languages other than English.

To ensure my participation has been beneficial for the TAG, I reached out to the chairs for feedback before deciding to run again. Both were very positive and strongly encouraged me to run again.

As someone not employed at a big tech company, I am not influenced by any particular company line. My only agenda is to lead the Web Platform to its full potential, and if re-elected, I’m willing to commit to spending the requisite hundreds of hours working towards that goal over the next two years. This was just the beginning, there is so much more important work to be done!

I would like to thank Open JS Foundation for graciously funding my TAG-related travel, in the event that I am re-elected, and both OpenJS Foundation and Bocoup for funding it during my first term.

Categories
Personal

Position Statement for the 2020 W3C TAG Election

Reading Time: 5 minutes

Update: I got elected!! Thank you so much to every W3C member organization who voted for me. 🙏🏼 Now on to making the Web better, alongside fellow TAG members!

Context: I’m running for one of the four open seats in this year’s W3C TAG election. The W3C Technical Architecture Group (TAG) is the Working Group that ensures that Web Platform technologies are usable and follow consistent design principles, whether they are created inside or outside W3C. It advocates for the needs of everyone who uses the Web and everyone who works on the Web. If you work for a company that is a W3C Member, please consider encouraging your AC rep to vote for me! My candidate statement follows.

Continue reading “Position Statement for the 2020 W3C TAG Election”
Categories
Personal

Leaving W3C

Reading Time: 4 minutesAbout a year ago, I announced I was joining W3C as a full-time staff member, to work on Developer Relations and education. Working at W3C was a dream come true and I can’t say I was disappointed. Over the past year I’ve worked with some amazingly brilliant people, hopefully increased awareness for web standards in the developer community and helped materialize the vision behind WebPlatform.org. It’s been a fun ride and working for a non-profit was very fulfilling. If somebody told me a year ago that I would decide to leave W3C on my own free will, I would’ve asked them what they were smoking. However, our future selves often surprise us and although it was the most difficult decision of my life, I recently decided to leave. July 31st will be my last day at W3C. I will attempt to describe the reasons below for anyone interested, but in no way does me leaving mean that I don’t deeply appreciate W3C or that I regretted joining. If I could go a year back, I would make the same choice.

Reason #1: I want to focus on other projects

I didn’t have much time to work on my pet projects, as my job was consuming pretty much the entire me. This is absolutely not W3C’s fault, it’s mine and a pretty common side effect of working from home. Pull requests kept piling up on Github, I didn’t have many ideas for new side projects or time for research & to come up with new techniques. I was able to work a bit on Dabblet and a WPD Prism plugin, as they were useful for WebPlatform.org, but for the most part, I wanted to work more on open source projects, do more research, blog more etc. I also recently signed a book deal with O’Reilly for a book on advanced CSS techniques (“CSS Secrets”, ETA Spring 2014) and I wanted to take some time off and write a great inaugural book, not just a decent one (and design it too!). I also kinda missed doing workshops or even client work, who knew!

Having more time will also mean I will be able to focus more on standards work, which is a huge passion of mine. I know it sounds odd to leave W3C to work more on …standards, but standards work was never a part of my job at W3C. If I wanted to devote time to actively participate in the CSS WG beyond the weekly telcon, or to the specification I edit, I would have to do it outside work hours. Obviously, I will still have to do it in my free time, but I recall having more of that when I was self-employed.

Reason #2: I want to grow

I want to be in a job that’s a challenge, that helps me grow and become a better professional. While I appreciate WebPlatform.org, I didn’t feel that doing front-end development & design on it made me particularly better at what I do, at least compared to other things I could have been doing in the past year. It could be a perfect opportunity to grow for someone else, but it wasn’t for me.

I did become a better public speaker over the past year, but I would likely be doing as many talks anyway. I got some valuable conference organizing experience from W3Conf, which I thoroughly enjoyed working on, but that was only a small part of my work.

Reason #3: Different direction

Had I stayed, my job description for the upcoming year would have a slightly different focus. Since W3C Developer Relations was a new activity, neither Doug (my manager) nor I were quite sure how we could make the biggest impact, so we were experimenting to some degree. A few months after I joined, WebPlatform.org launched and we slowly concentrated our efforts on that. If I had stayed for another year, my job would have an even stronger WebPlatform.org focus. Half of it would be front-end design & development and even writing documentation for a day per week. That meant I would have to cut down many parts of my job that I enjoyed and wanted to concentrate more on, such as public speaking and event planning, and though it includes some public-facing activities like gathering feedback from developers, I’d like to do even more of that. This was not a bad decision on W3C’s part — WebPlatform.org needs somebody concentrating on those aspects of it. However, although I strongly believe in the vision behind the project, this was not what I would personally enjoy doing.

Thank you, W3C

Even though I’m leaving W3C, it will always have a very special place in my heart. I met & worked with the most brilliant people I have ever met. Special mention to Amy, who did not just prove to be an intelligent, interesting and kind person, but also a great friend in the past couple of weeks that I got to know her better. I got to visit MIT and work from there for a while, which was an incredible experience. I got to contribute to WebPlatform.org which is a very ambitious and honorable project that I strongly believe in. I got to co-organize W3Conf, which turned out to a successful and fun conference.

Me leaving is a personal decision that has less to do with W3C and more to do with what I want out of life. But I’m going to sorely miss the W3C Team, the culture, the technical discussions. It’s been a fun ride and I’m grateful for the chance and the trust W3C placed in me. In fact, I wouldn’t be surprised to find myself working for W3C again at some point in the future, in some way or in a different role.

But for now, here’s to the future! I’m thrilled.

Want to work at W3C?

As you can imagine, there is one more opening now. 🙂 Are you a great designer with front-end development skills? Are you passionate about creating the best open web platform documentation on the Web? Apply now! You will be able to work from wherever in the world you want, whatever hours in the day you want, you will have great autonomy and a pretty cool boss. Sweet, huh?

Categories
Speaking

W3Conf in San Francisco, February 21-22

Reading Time: < 1 minuteYou might have heard about W3Conf, W3C’s conference for web designers and developers. This year, I have the pleasure of not only speaking there but also organizing it, along with Doug Schepers and designing the website for it.

Alongside with yours truly, it features an excellent lineup of amazing speakers like Eric Meyer, Alexis Deveria of caniuse.com fame, Nicolas Gallagher and many others. You can use coupon code VEROU to get $100 off the already affordable Early Bird price of $300. But hurry up, cause Early Bird prices are only valid until January 31st!

Hope to see you there!

 

Categories
Personal

lea＠w3․org

Reading Time: 2 minutesIn my recent post describing how I got into web development I wrote that I’m in the verge of some big changes in my life. The main one of them starts tomorrow. As of tomorrow, the above will be my professional email. Yes, you guessed it right; I’m joining the W3C team! Yes, the same W3C you all know and love 🙂 I decided to title this blog post with it, as I like how a 10 letter string manages to neatly summarize so much.

Working at W3C had been a dream of mine ever since I learned what a web standard is. As you probably know if you’ve been following my work, I’m a strong believer in open web standards. Even though proprietary technology might offer some short term benefits, in the long run only open standards can allow the Web to reach its full potential.

I’d like to especially thank the two people below (in chronological order). If it wasn’t for them, this dream would have never materialized:

  • Oli Studholme: I still remember our IRC conversation back in January. I was telling him how much I’d love to work for W3C, but “I’m not that good”. He repeatedly encouraged me to contact W3C and express my interest, despite my strong reluctance to do so. “Don’t be like the 15 year old boy that is too shy to ask the girl out” was the argument that finally convinced me. He even asked around to find which person I should contact.
  • Doug Schepers: If it wasn’t for Doug’s heroic efforts, this would have never happened. He believed in me from the start and did everything he could to for this to go through. He spent an incredible amount of time trying to help me, although I repeatedly bombarded him with a cornucopia of silly questions. 🙂 Over the course of these 6 months, he didn’t just become a colleague, but also a friend.
Thank you both. I’m deeply grateful.

I will be part of the W3C developer relations and web education efforts, working a lot with Doug (aka @shepazu). In practice, this means:

  • Help developers understand where standards are headed, and solicit early feedback on upcoming features.
  • Help Working Groups understand what developers need.
  • Help plan W3C developer events, including conferences
  • Speaking about open web technologies at conferences and other events
  • Writing articles and documentation about open web technologies
  • Making demos and tools that demonstrate and help authors understand web standards

In addition, I will be helping with the design of many W3C-related things, as I will be the only designer at W3C.

As you can see I’ll be wearing many hats, which is exactly what I love about this role! I had many tempting offers from big US companies that offered salaries with more digits and a lot of perks. However, my heart wanted W3C and this role was practically tailored to my talents and interests.

I’m honored to be a part of W3C and I’m looking forward to helping out.

<voice type=”fangirl”>I have to admit I’m also really looking forward to meeting Sir Tim Berners-Lee in person! :D</voice>

 

Categories
Thoughts

Vendor prefixes have failed, what’s next?

Reading Time: 5 minutesEdit: This was originally written to be posted in www-style, the mailing list for CSS development. I thought it might be a good idea to post it here as other people might be interested too. It wasn’t. Most people commenting didn’t really get the point of the article and thought I’m suggesting we should simply drop prefixes. Others think that it’s an acceptable solution for the CSS WG if CSS depends on external libraries like my own -prefix-free or LESS and SASS. I guess it was an failure of my behalf (“Know your audience”) and thus I’m disabling comments.

Discussion about prefixes was recently stirred up again by an article by Henri Sivonen, so the CSS WG started debating for the 100th time about when features should become unprefixed.

I think we need to think out of the box and come up with new strategies to solve the issues that vendor prefixes were going to fix. Vendor prefixes have failed and we can’t solve their issues by just unprefixing properties more early.

Issues

The above might seem a bold statement, so let me try to support it by recapping the serious issues we run into with vendor prefixes:

1. Unnecessary bloat

Authors need to use prefixes even when the implementations are already interoperable. As a result, they end up pointlessly duplicating the declarations, making maintenance hard and/or introducing overhead from CSS pre- and post-processors to take care of this duplication. We need to find a way to reduce this bloat to only the cases where different declarations are actually needed.

2. Spec changes still break existing content

The biggest advantage of the current situation was supposed to be that spec changes would not break existing content, but prefixes have failed to even do this. The thing is, most authors will use something if it’s available, no questions asked.  I doubt anyone that has done any real web development would disagree with that. And in most cases, they will prefer a slightly different application of a feature than none at all, so they use prefixed properties along with unprefixed. Then, when the WG makes a backwards-incompatible change, existing content breaks.

I don’t think this can really be addressed in any way except disabling the feature by default in public builds. Any kind of prefix or notation is pointless to stop this, we’ll always run into the same issue. If we disable the feature by default, almost nobody will use it since they can’t tell visitors to change their browser settings. Do we really want that? Yes, the WG will be able to make all the changes they want, but then then who will give feedback for these changes? Certainly not authors, as they will effectively have zero experience working with the feature as most of them don’t have the time to play around with features they can’t use right now.

I think we should accept that changes will break *some* existing content, and try to standardize faster, instead of having tons of features in WD limbo. However, I still think that there should be some kind of notation to denote that a feature is experimental so that at least authors know what they’re getting themselves into by using it and for browsers to be able to experiment a bit more openly. I don’t think that vendor prefixes are the right notation for this though.

3. Web development has become a popularity contest

I’ll explain this with an example: CSS animations were first supported by WebKit. People only used the -webkit- prefix with them and they were fine with it. Then Firefox also implemented them, and most authors started adding -moz- to their use cases. Usually only to the new ones, their old ones are still WebKit only. After a while, Microsoft announced CSS animations in IE10. Some authors started adding -ms- prefixes to their new websites, some others didn’t because IE10 isn’t out yet. When IE10 is out, they still won’t add it because their current use cases will be for the most part not maintained any more. Some authors don’t even add -ms- because they dislike IE. Opera will soon implement CSS animations. Who will really go back and add -o- versions? Most people will not care, because they think Opera has too little market share to warrant the extra bloat.

So browsers appear to support less features, only because authors have to take an extra step to explicitly support them. Browsers do not display pages with their full capabilities because authors were lazy, ignorant, or forgetful. This is unfair to both browser vendors and web users. We need to find a way to (optionally?) decouple implementation and browser vendor in the experimental feature notation.

Ideas

There is a real problem that vendor prefixes attempted to solve, but vendor prefixes didn’t prove out to be a good solution. I think we should start thinking outside the box and propose new ideas instead of sticking to vendor prefixes and debating their duration. I’ll list here a few of my ideas and I’m hoping others will follow suit.

1. Generic prefix (-x- or something else) and/or new @rule

A generic prefix has been proposed before, and usually the argument against it is that different vendors may have incompatible implementations. This could be addressed at a more general level, instead of having the prefix on every feature: An @-rule for addressing specific vendors. for example:

@vendor (moz,webkit,o) {
    .foo { -x-property: value; }
}

@vendor (ms) {
    .foo { -x-property: other-value; }
}

A potential downside is selector duplication, but remember: The @vendor rule would ONLY be used when implementations are actually incompatible.

Of course, there’s the potential for misuse, as authors could end up writing separate CSS for separate browsers using this new rule. However, I think we’re in a stage where most authors have realized that this is a bad idea, and if they want to do it, they can do it now anyway (for example, by using @-moz-document to target Moz and so on)

2. Supporting both prefixed and unprefixed for WD features

This delegates the decision to the author, instead of the WG and implementors. The author could choose to play it safe and use vendor prefixes or risk it in order to reduce bloat on a per-feature basis.

I guess a problem with this approach is that extra properties mean extra memory, but it’s something that many browsers already do when they start supporting a property unprefixed and don’t drop the prefixed version like they should.

Note: While this post was still in draft, I was informed that Alex Mogilevsky has suggested something very similar. Read his proposal.

3. Prefixes for versioning, not vendors

When a browser implements a property for the first time, they will use the prefix -a-. Then, when another browser implements that feature, they look at the former browser’s implementation, and if theirs is compatible, they use the same prefix. If it’s incompatible, they increment it by one, using -b- and so on.

A potential problem with this is collisions: Vendors using the same prefix not because their implementations are compatible but because they developed them almost simultaneously and didn’t know about each other’s implementation. Also, it causes trouble for the smaller vendors that might want to implement a feature first.

We need more ideas

Even if the above are not good ideas, I’m hoping that they’ll inspire others to come up with something better. I think we need more ideas about this, rather than more debates about fine-tuning the details of one bad solution.