The future of style

The Future of Style aggregates posts from various blogs that talk about the development of Cascading Style Sheets (CSS) [not development with Cascading Style Sheets]. While it is hosted by the W3C CSS Working Group, the content of the individual entries represent only the opinion of their respective authors and does not reflect the position of the CSS Working Group or the W3C.

Latest articles

Idea of the Week: Progressive Web Apps

Source: Web Directions Blog John • 26 September 2016 12:30 AM

At our Code 2016 conference a couple of months ago, Progressive Web Apps received quite a bit of attention. Marcos Caceres talked about how they are enabled by Service Workers, Elise Chant showed us how to use Manifests to install them, and several presenters referred to PWA in their presentations.

You might remember that PWAs were introduced as a concept by Alex Russell back at Web Directions 2015, so we figured it would be a good idea to use Scroll Magazine to put Progressive Web Apps in perspective.

Progressive Web Apps for everyone

By John Allsopp

The launch of the iPhone in 2007 was a watershed moment in modern technology, for all manner of reasons, but I want to focus on one particular aspect: its impact on the Web.

Back in the 1990s, those of us thinking about the future of Web design were already imagining a genuinely mobile Web. No small part of the impetus behind CSS, and the then radical “standards based” approach to Web development, revolved around the realisation that the Web wasn’t going to be desktop-only for ever (even if, at the time, laptop computers were rare and expensive, wi-fi non-existent, and accessing even email via a mobile phone was considered Jetsons-like futuristic).

The iPhone changed all that, despite in many ways being worse than the phones that came before it: slower CPUs, slower networks (2G only!), no physical keyboard. And as hard as it is to imagine now, it had no apps.

So, why did it succeed? My largely-impossible-to-verify speculation is that it was in no small part because it was the first genuinely usable mobile Web experience, and this set it apart from all other mobile devices at the time.

Almost no-one before had even tried – let alone come close to – making the mobile Web experience not totally suck. Apple did an end-run around these previous efforts. Controversially (among the handful of people aware of CSS media types at the time) it didn’t support the mobile media type in CSS, choosing rather to present the full web page, rendered into a theoretical 960px wide window and scaling the page to fit the ‘real’ viewport width of 320px.

I’d argue that the Web was critically important to the success of the iPhone, and the relationship between the two over the intervening nine years is instructive, and might point to the future of the Web.

That future looked, for many, kind of shaky not all that long ago. Indeed, some like Alex Russell – to whom we’ll return in a moment – argue that now is very much a watershed moment in the Web’s history. Apple’s interest in moving the Web forward, highly evident in the period between 2003 and around 2009 as they released a brand new best-of-breed browser – Safari – implemented then proposed as standards many of the features we now take for granted in modern web design (CSS animations, transitions, transforms, gradients, Web Fonts among many others), has slowed to a trickle.

Apple took years to adopt IndexedDB, among many other important Web technologies, and while all other browsers adopted an “evergreen” approach of continual improvement and automatic updating of both desktop and mobile browsers, Apple seemed stuck on an upgrade cycle for their browsers which marched in lock step with their Operating Systems, and ran in the order of years not weeks.

As the iOS App Store added more and more apps – they now number in the millions – the Web seemed less and less important to Apple (the same is not untrue of Android, too) and, indeed, to the future of computing. Web Apps were widely considered slow and ‘janky’, and lacked access to many of the device capabilities native apps could tap into that made Web content look endangered in the world of shiny 60FPS apps, with their access to the underlying device APIs and features, and – importantly – ability to be easily installed on the user’s home screen.

Meanwhile, Android is also an important part of this story. Coming from a company whose DNA was the Web, hope might have been had that Android would pick up the mantle, and make the Web a first class citizen. But Android increasingly went toe-to-toe with iPhone and the stock Android browser became increasingly outdated, even as Google was instrumental in moving the Web forward through Chrome.

Usage rates for the Web in comparison with native mobile apps fell, the importance of mobile computing rose and Wired famously declared the Web to be dead.

But. A funny thing happened on the way to the funeral.

All along, Google had been acquiring a team of smart, deeply experienced Web-native people, people who cared deeply about the Web, people exemplified by (although he’s far from alone) Alex Russell. Alex, who helped give the world Dojo, one of the earliest richly featured JavaScript frameworks, and ChromeFrame, an ingenious approach to getting a modern Web rendering engine into older Internet Explorer versions using ActiveX.

Folks like Alex, and Domenic Denicola, and many others at Google never lost faith in the Web.

Along with others at browser vendors like Mozilla and Opera and framework developers like Ember and elsewhere, these folks thought long and hard about what worked and what didn’t when it comes to moving the Web platform forward in an age of sophisticated native platforms like iOS and Android. They gathered and published their thoughts in the ‘Extensible Web Manifesto’. And over the last 12 months or so we’ve really started to see the fruits of this way of thinking, under the moniker of “Progressive Web Apps”.

Alex kicked this phase off when he published “Progressive Web Apps, escaping tabs without losing our soul“, and a few weeks later we were fortunate to have him open our Code 2015 conference with a keynote that expanded on these ideas.

The last 12 months has really seen these ideas start to become very much part of the everyday life of front end developers. Service worker is reaching a level of maturity in Chrome, and increasingly Mozilla, has strong interest from the Edge team at Microsoft, and even cautious public interest from the Webkit team. Other pieces of the puzzle, including push notifications, and Web Manifests (not to be confused with AppCache!) are becoming usable. And more importantly still, a pattern for developing Web apps that are progressive, that start life in the browser tab, and potentially migrate onto the user’s home screen has emerged.

Suddenly, I feel a renewed optimism for the Web, not simply that it can keep up with or compete with native, but that it can continue to embody the “webbiness” central to its success and importance.

The technologies that enable this new approach to Web development are maturing, and the philosophies and users’ mental models are still emerging, but it is a time of tremendous opportunity and promise. If you’re not already exploring Web Manifests, Service Workers, and Push notifications, these are low barrier to entry technologies that can be used to progressively improve your sites and apps today, even as we wait for their full adoption.

These are exciting times, full of promise and opportunity, and they don’t come around very often.

The emergence of CSS in the late 1990s, Ajax, jQuery and a more application-like Web experience in the early 2000s, mobile in the late part of the 2000s – just a small number of similar revolutionary shifts come to mind.

Don’t waste this opportunity.

directionad

Want more?

Like to see and read more like this? Be the first to score invitations to our events? Then jump on our once-a-week mailing list where we round up the week’s best reading and watching on all things Web. And you’ll get a complimentary digital copy of our brand new magazine, Scroll.


The post Idea of the Week: Progressive Web Apps appeared first on Web Directions.

Monday Profile: Alicia Sedlock

Source: Web Directions Blog John • 19 September 2016 01:03 AM

Alicia SedlockAt our Code 16 conference, Alicia Sedlock gave a very popular presentation on testing – not, you might think, the most rivetting subject but one made practical and accessible by Alicia.

It probably didn’t hurt that Alicia featured a few snaps of her favourite companion, Mabel the hedgehog. Here’s the interview we conducted with Alicia (but not Mabel) for Scroll Magazine before the conference.

Q What made you decide you could do this for a living?
A Well, the glamourous way it all began was sitting on my parents’ Dell PC making custom LiveJournal and MySpace layouts. Seriously. I thought I’d end up being able to make layouts for famous Internet personae and make a lot of money doing it.

That’s what sparked my initial web development interests, which inspired me to sign up for my high school’s Intro to Web Design elective. It was a half year elective that opened me up to what HTML really was, how CSS works, and how to do animations and interactivity in Flash. I went on to sign up for the full year course in my junior year, and as independent study in my senior year, and ended up majoring in Web Design and Interactive Media in college. I was always a creator at heart (don’t even ask me how many art mediums I’ve tried to pick up) and web development stuck, for some reason.

Q Have you ever coded live on stage, or in front of an audience? How did it go?
A I recently attempted my first live code talk at my work, giving a Lunch & Learn talk to our development team about CSS flex and grid layouts. I thought, “I know this fairly well, I’ll just dive right in!” Turns out, that didn’t work too well. Debugging on a giant projector is somehow even more nerve wracking than anything I’ve done in front of a group before.

Q How do you further develop and extend your skills? Books, courses? Noodling by yourself?
A I follow a lot of people on Twitter. A lot. And even though it’ll take me all day to catch up on my timeline, I get exposed to a lot of new and upcoming things – SVG, React, animations, accessibility, new web standards, you name it.

I essentially use it as a filter, so that when a topic comes across the feed that I’m excited about, I have a place to start digging in. I end up reading a lot of blog posts, forking a lot of pens on CodePen, messing around with them, then building something small and dinky to get my teeth into something.

Q Is it better to learn HTML then CSS then JavaScript, or JavaScript then HTML then CSS, or all three at once, or something else?
A I think it depends on what your goals are for learning. If your goal is to have a visual interface that you can interact with to do cool things, then getting a handle on HTML/CSS before JavaScript might be the better approach. If you don’t care about interfaces and simply want to punch out crazy computations or algorithms, perhaps learning JavaScript first would get you there. I’d say it’s a case-by-case basis.

Q What’s the best way to get more women coding?
A There are already a lot of women in programming. It’s about how do we keep them from leaving the industry, which requires looking at the hard truth about why women leave the industry. Lack of work life balance, lack of support for new mothers, and then, you know, the constant harassment and abuse many women experience throughout their careers, both online and in their workplaces. So if we want to keep women in the industry, we need to address these types of systemic issues right where they are – in our workplaces, our open source communities, our conferences.

Q Frameworks. What’s your take? Are they good, bad or does it depend on how you use them?
A It absolutely depends on how and why you use them. The impression I get these days is that many developers are looking for THE framework, the framework that they’ll use for every project for the rest of their days. If they work on one particular kind of application, and make that same application over and over again, then maybe that can be a reality. But every framework has their upsides and downsides, so for the majority of us, it’ll never be that easy.

Developers need to really look at frameworks and say, “What is this really giving me that I can’t live without? What problems am I facing that this framework solves that I can’t solve without it?” I’d say the mentality of “always use a framework” is more dangerous than the frameworks themselves.

Q Tabs or spaces?
A Soft tabs. Fight me.

Q What’s on your horizon?
A To be quite honest, I’m not really sure. None of my career thus far has been part of a long-term plan. I only end up making decisions as opportunities arise. However, the one thing I would like to achieve eventually is to make a game that works in the browser, and on all devices.

directionad

Want more?

Like to see and read more like this? Be the first to score invitations to our events? Then jump on our once-a-week mailing list where we round up the week’s best reading and watching on all things Web. And you’ll get a complimentary digital copy of our brand new magazine, Scroll.


The post Monday Profile: Alicia Sedlock appeared first on Web Directions.

New Persian character picker

Source: ishida blog » cssr12a • 16 September 2016 06:26 AM

Picture of the page in action.

A new Persian Character Picker web app is now available. The picker allows you to produce or analyse runs of Persian text using the Arabic script. Character pickers are especially useful for people who don’t know a script well, as characters are displayed in ways that aid identification.

The picker is able to produce UN transcriptions of the text in the box. The transcription appears just below the input box, where you can copy it, move it into the input box at the caret, or delete it. In order to obtain a full transcription it is necessary to add short vowel diactritics to places that could have more than one pronunciation, but the picker can work out the vowels needed for many letter combinations.

See the help file for more information.

Minutes Telecon 2016-09-14

Source: CSS WG Blog Dael Jackson • 15 September 2016 12:13 AM

Full Minutes

Timeline: 5 dynasties & 10 kingdoms

Source: ishida blog » cssr12a • 14 September 2016 08:54 AM

This shows the durations of dynasties and kingdoms of China in the 900s. Click on the image below to see an interactive version that shows a guide that follows your cursor and indicates the year.

Chart of timelines

See a map of territories around 944 CE.

W3C Web.br is the main Web conference in Brazil, organized b…

Source: W3C's Cascading Style Sheets home page14 September 2016 07:30 AM

13 Oct 2016 W3C Web.br is the main Web conference in Brazil, organized by W3C Brazil, CGI.br, NIC.br and CEWEB.br. This year's special focus is on the Web of Things and Finance. Keynote speakers include Dave Raggett and Bert Bos. (Conference in Portuguese.)

CSS Dev Conf is a conference about CSS in San Antonio TX (US…

Source: W3C's Cascading Style Sheets home page14 September 2016 07:30 AM

17 Oct 2016 CSS Dev Conf is a conference about CSS in San Antonio TX (USA), on 17–19 October. A feature of this conference is that part of the conference program is determined by vote.

Countdown to Direction 16

Source: Web Directions BlogJohn • 13 September 2016 12:30 AM

10th anniversaryWe’re counting down to Direction, our big end of year conference, the 10th anniversary of our very first event. For this year we’ve made some changes (while keeping to the essence of the event thousands of attendees over the last decade have found so engaging and valuable). We’d love you to join us, as we set sail for the next exciting decade.

Long-time (and even more recent) attendees of Web Directions will probably have noticed a few changes across all the various activities we run.

But none is bigger than the (r)evolution of our major annual event, which for the last decade since it started in 2006 has been known as Web Directions.

Way back then, our focus was almost entirely on Web design and our audience was that many-hatted expert of all things Web, from HTML and CSS to visual design, usability and accessibility, content, SEO and much more besides.

But just as the Web, and the community of professionals around this core technology have changed profoundly in the last decade, we’ve changed too. We added tracks to help those specialising in specific areas of practice develop their knowledge and skills. And we found, over time, that it was the ideas that ran across specialisations that particularly engaged and energised our audience.

Over the decade, and particularly in recent years, we’ve developed new conferences focusing on specific areas of practice, like Code for front-end engineering, Respond for web and interaction design, and most recently this year Transform, focusing on the revolution occurring around the world in Government Services Delivery. All these will continue — and, indeed, grow — into the future.

As we turned toward the second decade of Web Directions, we spent a lot of time (and I mean a lot) thinking about the role of our “big” event. From its name (we’ve felt for a while now the word “Web” is limited in its reach and appeal, backed up by emails from people who’ve told us their boss won’t send them to a “Web Design” conference), to how many tracks it would comprise, to the overall focus of the event.

And so, after a lot of consideration, and many conversations with people close to the events,  was (re)born — Direction.

The name both links to our past and looks to the future. The choice of the singular “Direction” over the plural “Directions” was very deliberate, and aims to capture the key mission of the event. When we know where we want to go, we ask for directions. But on the bigger journeys of our life, both personal and professional, there is no single destination, no one specific place we are looking to go. Rather, there’s an overall direction in which we are headed. And it’s that choice of direction that this event is all about. This idea is for me captured poignantly in Robert Frost’s perhaps too-often quoted poem “The Road Not Taken”

Two roads diverged in a wood, and I—
I took the one less traveled by,
And that has made all the difference.

Each of us likely has a story of paths taken and not: junctures in our lives, personal and professional. Those of us who work in and on the Web, and at the intersection of design and technology, almost certainly did not follow the sorts of paths associated with more traditional professions and careers. Our ‘field’ (a term too constrained to describe the landscape we inhabit) continues to evolve (we continue to evolve it). The novel ideas and skills and techniques we learned last year become “table stakes”, even obsolete – replaced, superseded or subsumed by what comes next. And keeping up is both exciting and challenging. This restlessness almost defines our field.

At the heart of our events (and everything else we’ve done over the last decade and more, and at the heart of my own writing, speaking, and even the software I’ve written over the last 20 years) has been the effort to make sense of where we are, and where we are going. I think this is in no small part why such ground breaking, and diverse ideas as OOCSS (first introduced to the world by a then little known Nicole Sullivan at Web Directions North in 2009) and “The New Aesthetic” (an idea originally outlined by James Bridle at Web Directions South 2012), alongside now world renowned speakers who first spoke at our events, have originated at our conferences. We spend a significant part of our lives here thinking about these divergent roads, and finding ways to introduce them to our audience.

And it’s this that’s the animating focus of Direction. Not a prescriptive “here are the things you should be doing”, not directions to get you from A to B, but ideas about which direction to take, about where our field at the intersection of design, the Web and technology seems to be going.

Over the next two months, as we lead up to the 10th anniversary of our first event, and the first Direction conference (which will also be very familiar in many ways from previous Web Directions you’ve been to) I’ll be going into more detail about the sessions we’ve programmed, and my thinking behind what interested me about the ideas, and the experts delivering them, and how all this fits into the broader themes and patterns and trends I see emerging in our field.

But if there’s a theme, among others that will emerge in the coming weeks and at the conference, it’s that we don’t face that fork in the road just once in our careers in this field: we face these choices, in large ways and small, over and over.

And when we choose a path, it’s also to the exclusion of the road not taken, so these choices really do matter, they shape our lives, sometimes a little, and sometimes much more.

Which is an enormous privilege that we have – in many other fields, the choices and opportunities are far more constrained.

But there’s no doubt it can be challenging to face this constant change, the incessant requirement to keep up with currents of practice, with technologies and ideas.

The phrase “I’m too old for this” passes my lips perhaps bit too frequently. But then I look to the work emerging where design and technology meet, on the Web, with physical objects, in the built environment, and the excitement overcomes my anxiety, as I’m sure it does for you. And ironically, it keeps me young.

Direction is all about that excitement, helping fuel it, through amazing presentations, and experiences outside the theatre, and channel it toward what comes next.

I can’t wait for it to come around, and to share it with you.

The post Countdown to Direction 16 appeared first on Web Directions.

The CSS WG and the SVG WG updated the Working Draft of Web A…

Source: W3C's Cascading Style Sheets home page13 September 2016 12:00 AM

13 Sep 2016 The CSS WG and the SVG WG updated the Working Draft of Web Animations

Monday Profile: Greg Rewis

Source: Web Directions BlogJohn • 12 September 2016 12:06 AM

Greg RewisOur series of interviews with conference speakers for Scroll Magazine has proven very popular, both for the insights each has given into that particular speaker but also how they compare to each other. This week, we profile Greg Rewis, speaker at Code 16.

For another perspective, later in the week you can also see the video interview I conducted with Greg.

Q: What made you decide you could do this for a living?

A: I actually kind of tripped into my career. I was working in the late 80s in Denmark at a newspaper and magazine publisher as a journalist. And one day, some boxes containing some Mac IIfx computers showed up. I was the only one in the office that had any experience on a Mac, so I went about setting them up, installing software (QuarkXPress 1.12 and Illustrator 88!), and showing my colleagues how to work them. Any time someone would get stuck, I ended up being the person they called. Needless to say, my career as a journalist quickly turned into my career in IT.

Through that transition, I began thinking about the software we were using to create our publications, which took me to the first MacWorld in Berlin. I had the good fortune to talk with a couple of developers out of Hamburg who were building a publishing system based around QuarkXPress. A few conversations later and a trip to Hamburg and I had a new job as the product manager for their publishing system.

A few years later, we began working on a project to mark up the stories in the database for re-use on things like CD-ROMs. That little project turned into one of the first HTML authoring tools, originally named GoLive, which would become GoLive Cyberstudio, and eventually Adobe GoLive. After Adobe’s acquisition of GoLive, I “defected” to Macromedia to help build Dreamweaver. Of course, the joke was on me, as Macromedia was eventually acquired by Adobe.

As a product manager, you have an opportunity to do presentations. And I ended up, not only liking to do presentations, but actually being really good at it! So somewhere along the line, I transitioned to being a full time developer evangelist.

 

Q: Have you ever coded live on stage, or in front of an audience? How did it go?

A: All the time. I actually really enjoy live coding, as I think it helps establish credibility. As a developer evangelist, it’s important that the audience understands that I really do know what I’m talking about and I’m not simply doing a marketing or sales pitch.

And, at least for me, live coding helps with that. The one key is that the coding actually accomplishes something — in other words, I’m doing it so that I can simultaneously explain something without having someone “read ahead” on a slide.

 

Q: How do you further develop and extend your skills? Books, courses? Noodling by yourself?

A: A large part of my job is “noodling”. In fact, that’s how almost every demo I’ve ever done has come about. Whenever I’m learning something new, I try to think “what could I build”? As an example, when I joined Salesforce and began learning the platform, I immediately pulled out an old project built on a different technology stack and thought “how could I rebuild this for Salesforce”. I find that building my own project helps me learn faster than simply doing someone else’s tutorial.

 

Q: Is it better to learn HTML then CSS then JavaScript, or JavaScript then HTML then CSS, or all three at once, or something else?

A: On the question of HTML or CSS, I think they should probably be learned together, because without CSS, HTML is pretty boring. And although there are roles in which you only need HTML and CSS, I think most front-end roles today also require a good understanding of JavaScript.

The important thing about learning JavaScript is to learn JavaScript, and not a framework or library. I know a lot of developers that started with jQuery, and that’s fine. But even if you are using jQuery (or Angular/React/Backbone/etc), it behoves you to understand the plain vanilla JavaScript. Because at the end of the day, even if you are “writing jQuery”, you’re still writing JavaScript.

 

Q: What’s the best way to get more women coding?

A: The simple answer is to get them interested. But doing that means that we have to do two things. The first is to break down the typical nerd or geek stereotype in a way that makes young girls think “I could see myself doing that”. Having the typical image of a developer being someone who is socially awkward, with no sense of style, would make even a younger me not want to pursue that job!

The other — and perhaps much harder — challenge is to craft an environment where those girls and women who choose to become developers feel safe and welcome. No one wants to work in a hostile environment, but that is what many women in the industry feel about working as developers.

 

Q: Frameworks. What’s your take? Are they good, bad or does it depend on how you use them?

A: Frameworks can be awesome — but they also can be a crutch. The important thing, as I mentioned before, is that you know how to survive without them. I once saw someone include jQuery in order to do something that could’ve been achieved in less than 10 lines of plain JavaScript.

 

Q: Tabs or spaces?

A: For? It’s actually quite simple. Tabs are for indentation, spaces separate words.

 

Q: What’s on your horizon?

A: Setting off to sail around the world … in 5 years. But before that, continuing to learn and grow as a developer. It’s really awesome (and tiring) to be in an industry that is growing and changing so quickly.

 

The post Monday Profile: Greg Rewis appeared first on Web Directions.

Minutes Telecon 2016-09-07

Source: CSS WG Blog Dael Jackson • 08 September 2016 12:08 AM

Full Minutes

Notes on case conversion

Source: ishida blog » cssr12a • 07 September 2016 04:03 PM

Examples of case conversion.

These are notes culled from various places. There may well be some copy-pasting involved, but I did it long enough ago that I no longer remember all the sources. But these are notes, it’s not an article.

Case conversions are not always possible in Unicode by applying an offset to a codepoint, although this can work for the ASCII range by adding 32, or by adding 1 for many other characters in the Latin extensions. There are many cases where the corresponding cased character is in another block, or in an irregularly offset location.

In addition, there are linguistic issues that mean that simple mappings of one character to another are not sufficient for case conversion.

In German, the uppercase of ß is SS. German and Greek cannot, however, be easily transformed from upper to lower case: German because SS could be converted either to ß or ss, depending on the word; Greek because all tonos marks are omitted in upper case, eg. does ΑΘΗΝΑ convert to Αθηνά (the goddess) or Αθήνα (capital of Greece)? German may also uppercase ß to ẞ sometimes for things like signboards.

Also Greek converts uppercase sigma to either a final or non-final form, depending on the position in a word, eg. ΟΔΥΣΣΕΥΣ becomes οδυσσευς. This contextual difference is easy to manage, however, compared to the lexical issues in the previous paragraph.

In Serbo-Croatian there is an important distinction between uppercase and titlecase. The single letter dž converts to DŽ when the whole word is uppercased, but Dž when titlecased. Both of these forms revert to dž in lowercase, so there is no ambiguity here.

In Dutch, the titlecase of ijsland is IJsland, ie. the first two letters have to be titlecased.

In Greek, tonos diacritics are dropped during uppercasing, but not dialytika. Greek diphthongs with tonos over the first vowel are converted during uppercasing to no tonos but a dialytika over the second vowel in the diphthong, eg. Νεράιδα becomes ΝΕΡΑΪΔΑ. A letter with both tonos and dialytika above drops the tonos but keeps the dialytika, eg. ευφυΐα becomes ΕΥΦΥΪΑ. Also, contrary to the initial rule mentioned here, Greek does not drop the tonos on the disjunctive eta (usually meaning ‘or’), eg. ήσουν ή εγώ ή εσύ becomes ΗΣΟΥΝ Ή ΕΓΩ Ή ΕΣΥ (note that the initial eta is not disjunctive, and so does drop the tonos). This is to maintain the distinction between ‘either/or’ ή from the η feminine form of the article, in the nominative case, singular number.

Greek titlecased vowels, ie. a vowel at the start of a word that is uppercased, retains its tonos accent, eg. Όμηρος.

Turkish, Azeri, Tatar and Bashkir pair dotted and undotted i’s, which requires special handling for case conversion, that is language-specific. For example, the name of the second largest city in Turkey is “Diyarbakır”, which contains both the dotted and dotless letters i. When rendered into upper case, this word appears like this: DİYARBAKIR.

Lithuanian also has language-specific rules that retain the dot over i when combined with accents, eg. i̇̀ i̇́ i̇̃, whereas the capital I has no dot.

Sometimes European French omits accents from uppercase letters, whereas French Canadian typically does not. However, this is more of a stylistic than a linguistic rule. Sometimes French people uppercase œ to OE, but this is mostly due to issues with lack of keyboard support, it seems (as is the issue with French accents).

Capitalisation may ignore leading symbols and punctuation for a word, and titlecase the first casing letter. This applies not only to non-letters. A letter such as the (non-casing version of the) glottal stop, ʔ, may be ignored at the start of a word, and the following letter titlecased, in IPA or Americanist phonetic transcriptions. (Note that, to avoid confusion, there are separate case paired characters available for use in orthographies such as Chipewyan, Dogrib and Slavey. These are Ɂ and ɂ.)

Another issue for titlecasing is that not all words in a sequence are necessarily titlecased. German uses capital letters to start noun words, but not verbs or adjectives. French and Italian may expect to titlecase the ‘A’ in “L’Action”, since that is the start of a word. In English, it is common not to titlecase words like ‘for’, ‘of’, ‘the’ and so forth in titles.

Unicode provides only algorithms for generic case conversion and case folding. CLDR provides some more detail, though it is hard to programmatically achieve all the requirements for case conversion.

Case folding is a way of converting to a standard sequence of (lowercase) characters that can be used for comparisons of strings. (Note that this sequence may not represent normal lowercase text: for example, both the uppercase Greek sigma and lowercase final sigma are converted to a normal sigma, and the German ß is converted to ‘ss’.) There are also different flavours of case folding available: common, full, and simple.

Monday Profile: Stephanie Rewis

Source: Web Directions Blog John • 05 September 2016 02:40 AM

One of the things I’ve appreciated most with Scroll Magazine, has been the opportunity to get to know some of our speakers better, particularly some of the things you might not necessarily know about them.

This week we’re featuring an interview with Stephanie Rewis, a long time contributor through books, blog posts, workshops and presentations to the Web. Keep an eye out for my interview with Steph, and more in coming weeks.

Q: What made you decide you could do this for a living?

A: I’ve always had an interest in how the brain works and it seemed logical to introspect, identify my innate skills, and find a career that utilized those. I love puzzles, research, and detective work. I believe life is about continual learning. I didn’t know much about code, but thought it might make use of those abilities.

After taking an HTML class, I was interested, but decided I would rather learn at my own speed. I did tutorials 15 hours a day for the first year. I got friends to let me build websites for them (you don’t know what you don’t know until you try things). I joined a mailing list and obsessively asked questions. As my questions were answered, I asked harder questions and answered the easier ones from new folks.

As time went on, I was doing more answering than asking. Business owners who planned to build their own site then found it to be harder than they anticipated would contact me offlist and ask what I would charge to build it for them. And that’s when I realized I could do this for a living. People helped me and asked nothing in return, I passed that knowledge on to others, and I never did any marketing. Starting my business was organic.

Q Have you ever coded live on stage, or in front of an audience? How did it go?

A Oh yes. I used to code on stage all the time. But for me, writing code at my desk as opposed to writing it in front of an audience uses different brain modalities. When you’re nervous, you may not notice a typo, a missing semi-colon, etc. And then you can’t see it and the audience has to help you figure out why it isn’t working. It’s a little nerve-wracking.

Over time, I’ve tried different methods of showing code. Sometimes I’ve commented code out in chunks and then uncommented bit by bit while explaining it and showing what it does. Nowadays, I lean more toward making a movie of writing and showing it and then talking through it while it plays, which also saves time from bouncing between Keynote and a browser.

Q How do you further develop and extend your skills? Books, courses? Noodling by yourself?

A I stay pretty busy these days, so I find myself doing more reading of blogs and articles by people I trust (many times discovered via my RSS reader — Twitter). If I’m searching for specific information, I limit my search parameters to the past year. If a site doesn’t put a date on their posts, I get highly irritated and disregard their information. Web information is not timeless. Things change at a rapid pace. When I get books, I tend to cherry pick the information I read rather than doing a cover to cover read.

Q Is it better to learn HTML then CSS then JavaScript, or JavaScript then HTML then CSS, or all three at once, or something else?

A They work as a team. HTML — or good, accessible, semantic markup — should be the root of all things. You should understand what markup is appropriate to use in specific circumstances. HTML is the only one in the group that could stand alone if needed. If your JS and CSS were turned off, your HTML should look like a nice logical outline with headings, lists, and paragraphs.

CSS is, of course, used for all styling. As CSS has become much more powerful, it’s best for performance reasons to create animations and transitions using CSS instead of JS. More than likely, if you can do it with CSS, you probably should.

JS is used to enhance the experience. And in the true spirit of progressive enhancement, content should be available without it. Maybe it won’t be as sexy, but the user doesn’t miss important things. To me, this is sadly missing in many JS frameworks today. And newer web developers don’t seem to understand why that’s not a good thing, and they don’t attempt to make their sites accessible.

Q What’s the best way to get more women coding?

A That’s a loaded question, isn’t it? I’ve heard a lot of good ideas about making our work environment more conducive to keeping women, and I think those are great. But quite honestly, I think the root issue is far deeper. It begins with the media and our culture. Where are the amazing geek role models on TV shows (yes, there are a slim few lately)? What is held up to girls as important when they’re young? Is it being smart, or is it being thin and beautiful?

What if we put less influence on the Kardashians — women who have achieved nothing but a lot of plastic surgery and media attention — and more on women who have made really amazing technical and scientific achievements? What if we made being smart sexy? I believe that attracting young women to our industry starts with changing the expectations put on them as a culture.

Q Frameworks. What’s your take? Are they good, bad or does it depend on how you use them?

A In the case of JS frameworks, I strongly believe you should be well- grounded in plain vanilla JS and progressive enhancement. Then, if you choose to use a framework, yes, use it smartly and accessibly.

In the case of CSS frameworks — I have strong opinions since I’ve used some and written one. I found in using a couple over the years that they tended to be overbloated and far more than I would write myself. I either didn’t need a good bit of what they included, or I needed to change and override so much of it that it became even bigger. It’s hard to be all things to all sites that might want to use your framework.

That said, I lead the CSS framework we’ve written for the Salesforce Lightning Design System. We work hard to start with reusable micro- patterns and to only write what we actually need. We have the luxury of writing for our specific enterprise ecosystem. It’s not meant to be a generic, “use it for everything” framework. So while some people using our framework may override the branding colors (via tokens or variables), in the end, most want their components to look like the new Salesforce Lightning experience. It’s a great time-saver for both internal and external developers building on our platform.

Q Tabs or spaces?

A I could barely care less than I do. When I was doing a lot of contracting for agencies, I regularly switched my editor to output whatever they preferred. Our team currently uses spaces (I had to look at my preferences to tell you that. LOL). I set the translate_tabs_to_spaces to “true” and then I never think about it again. There are other things I’m more passionate about — like the code that follows those tabs or spaces.

Q What’s on your horizon?

A In five years, Greg and I will be taking off on Amritha, our Lagoon 400 catamaran, to circumnavigate the globe for 8-10 years. Until then, I’m absolutely loving my role at Salesforce. It’s a place where I’m well- supported as a human and encouraged to continually learn, grow, share, and lead. I can’t think of a better, more challenging role to work in until we exit.


Like to watch and read more like this? Be the first to score invitations to our events? Then jump on our once a week mailing list where we round up the week’s best reading and watching on all things Web. And you’ll get a complimentary digital copy of our Scroll magazine.


The post Monday Profile: Stephanie Rewis appeared first on Web Directions.

Minutes Telecon 2016-08-31

Source: CSS WG Blog Dael Jackson • 01 September 2016 12:51 AM

Language subtag tool now links to Wikipedia

Source: ishida blog » cssr12a • 30 August 2016 10:38 AM

The language subtag lookup tool now has links to Wikipedia search for all languages and scripts listed. This helps for finding information about languages, now that SIL limits access to their Ethnologue, and offers a new source of information for the scripts listed.

Picture of the page in action.

Right-to-left scripts

Source: ishida blog » cssr12a • 25 August 2016 07:32 PM

These are just some notes for future reference. The following scripts in Unicode 9.0 are normally written from right to left.

Scripts containing characters with the property ARABIC RIGHT-to-LEFT have an asterisk. The remaining scripts have characters with the property RIGHT:

In modern use

Adlam
Arabic *
Hebrew
Nko
Syriac *
Thaana *

Limited modern use

Mende Kikakui (small numbers)
Old Hungarian
Samaritan (religious)

Archaic

Avestan
Cypriot
Hatran
Imperial Aramaic
Kharoshthi
Lydian
Manichaean
Meroitic
Mandaic
Nabataean
Old South Arabian
Old North Arabian
Old Turkic
Pahlavi, (Inscriptional)
Palmyrene
Parthian, (Inscriptional)
Pheonician

Minutes Telecon 2016-08-24

Source: CSS WG Blog Dael Jackson • 25 August 2016 01:35 AM

Full Minutes

Minutes Telecon 2016-08-17

Source: CSS WG Blog Dael Jackson • 18 August 2016 12:57 AM

Full Minutes

Minutes Telecon 2016-08-10

Source: CSS WG Blog Dael Jackson • 11 August 2016 01:38 AM

Full Minutes

Minutes Telecon 2016-08-03

Source: CSS WG Blog Dael Jackson • 04 August 2016 01:06 AM

Full Minutes

Color Function Syntax Update

Source: CSS WG Blog fantasai • 29 July 2016 01:12 AM

From Tab’s blog post on the recent changes to the Color module:

Yesterday I committed a few changes to the CSS Color spec that are proving a little controversial to people without any background on the changes. Hopefully this will help!

Specifically, I made it so that the rgb() function (and others) can now use the syntax rgb(0 255 0 / 50%) for half-transparent green. Previously you’d write that as rgba(0, 255, 0, 50%). Why’d I make this change?

This is part of a general overhaul to how CSS defines functions that fantasai and I are pushing. The overall strategy is written up on our wiki, but the general idea is that CSS has some informal rules about how to organize things and use certain punctuation characters. In particular, in CSS properties we normally just separate values with spaces, relying on distinguishable syntax (like <string> vs <number> vs <length>) or just careful ordering to keep things unambiguously parseable. We use punctuation separators only for very specific purposes: commas are used to separate repetitions of a base value (like layers in the background property, or font names in the font-family property), and occasionally, when we can’t do anything better, a slash is used to separate two otherwise-ambiguous values (like font-size vs line-height in the font shorthand, transition-delay vs transition-duration in the transition shorthand, or the multiple pieces of syntax in a border-image layer).

However, functions violated those rules. They used commas extensively and somewhat inconsistently, just to separate values from each other. On the one hand, this makes CSS functions look slightly more like functions in a traditional programming language; on the other hand, it meant you had to learn a different mental model of how CSS’s syntax works, and type a bunch of comma characters that weren’t actually necessary. fantasai and I have gradually come to the position that it’s worthwhile to unify CSS’s syntaxes, making functions more property-like. (Our position can be summed up aptly as “functions are just named chunks of CSS syntax”.)

Color

So that brings us to the Color spec. Color 3 was already a function-full spec, and Color 4 more than doubles that number, adding hwb(), gray(), lab() and lch(), and color(). The first four of those look similar to the existing rgb()/etc functions, just taking a couple of numbers, so they were originally designed with the same syntax, separating every number with commas.

But color() was a bit more complex, more like a CSS property. It had to take a colorspace name, an arbitrary number of arguments to the colorspace, an alpha, then finally a fallback value in case the colorspace wasn’t loaded or was invalid. Putting commas between every value there just got ridiculous, not to mention made it difficult to read; in particular, it was hard to tell where the colorspace arguments ended and the alpha began.

So, I opened Issue 266 about it, and discussion eventually led us to making it use CSS property syntax pretty much exactly: color() takes a comma-separated list of colors (each one serving as fallback for the previous), and within each color, everything is space-separated. Because colorspaces can take an arbitrary number of numeric parameters, the alpha value was ambiguous (hard to even tell whether or not there was an alpha at a casual glance), and so we employed the slash to separate it visually from the parameters.

At this point, tho, it was slightly weird to have this one color function use this particular syntax form, while none of the others used anything like it. Welp, all the color functions were on our wiki page’s list of things to overhaul anyway, so bombs away! We went ahead and changed all the new functions to use the same syntax (all values space-separated, with an optional slash-separated alpha), and then added a new syntax variant to the old functions with the same form.

(I stress, this is a new variant syntax, not a replacement. All your old rgb(0, 255, 0) code is fine and will never be incorrect. We’re just classifying it as a legacy syntax; we’ve got a handful of those cluttering up CSS specs.)

So, now all the color functions use the same syntax form, and they all agree with our general push to make functions resemble properties more closely. It may feel a little weird at first, but I think you’ll appreciate it as you get used to it (a few characters less typing, at the very least). And we’ve been edging this way for quite a while – as far back as linear-gradient() we were trying to use commas reasonably, with the complex sizing/positioning part up front completely space-separated and commas used only to separate the color-stop repetitions.

Minutes Telecon 2016-07-27

Source: CSS WG Blog Dael Jackson • 28 July 2016 01:19 AM

Full Minutes

Idea of the Week: Ricky Onsman

Source: Web Directions BlogJohn • 26 July 2016 12:30 AM

Code conferenceWith our Code conference starting in Sydney in just a few days and in Melbourne next week, our Idea of the Week this week comes from the conference’s Scroll magazine and its editor, Ricky Onsman.

As he explains, you should definitely see what your Sydney and Melbourne code-focused meetups are up to this week and next.

Meetups at Conference Time

by Ricky Onsman

Web Directions has long been a sponsor of meetups that have a focus on web technologies. Often, these meetups in different cities around Australia provide an opportunity for conference speakers to test material in front of a willing and supportive audience, in the process helping to promote the conference and also attracting more people to the meetup.

For that reason, meetups that happen around the time of a conference event are often exciting affairs, with more people than usual and an international flavour.

The SydCSS meetup held the night before our Respond conference in Sydney in April was just such an event. One hundred and thirty of us turned up to the rather cool rooftop bar of the Pyrmont Bridge Hotel on a balmy Sydney early autumn evening, where we found a generous bar tab and regular rounds of tasty snacks circulating through the room. Classy, or what?

There was a real air of excitement as the usual buzz of friends and colleagues seeing each other was heightened (literally!) by the spectacular semi-outdoor setting, as well as the awareness that tonight would be graced by two major speakers from Respond.

Rachel Ilan Simpson is an American UX Designer based in Munich who works on the Chrome team for Google. Her Respond presentation was to be a version of a talk she’d originally created and presented with Guy Podjarnik, and this meetup would give her the chance to test some of the material solo with a live Australian audience.

The topic Rachel addressed was one with which developers and designers alike often struggle: finding the balance between website Usability and Security. Users want sites that can guarantee the security and safety of any information they provide, but they don’t want things to get in their way, like passwords.

Rachel took us through several aspects of the situation, looked at some of the core issues, made us cringe at some of the statistics and wince at some of the examples, and offered some ways all of this might be addressed. It was an excellent preview of her longer presentation at Respond itself.

The other main speaker was Russ Weakley, an Australian designer, front end developer and trainer based in Sydney who has built an international reputation not only as a CSS expert, but as someone who can make the often arcane world of stylesheets comprehensible even to beginners, while inspiring veterans to look at new ways of using CSS.

On this occasion, Russ took us into the world of CSS Property Values and the syntax required to use them properly. That might sound dry – but have you ever seen a Russ Weakley talk? Dry, it was not. He’s a very funny speaker who nonetheless has an excellent grasp of his subject, and that special knack of clarifying things that often look dauntingly complicated.

He even came up with a code puzzle for us to solve, with the winners taking home copies of the excellent Offscreen magazine.

Both speakers received a very warm reception from a knowledgeable crowd. The post-talk questions and answers were informed and technical, which helped to give the whole evening a comfortably techy feel.

As with most meetups, there were short announcements of local projects, opportunities, events and jobs, then a lot of chat until the food and drinks ran out. A top night out.

In Melbourne, a similar event took place the day after the conference, in the form of a mega meetup between the MelbCSS, MelbJS and BeResponsive groups. That time, Jen Simmons and Ryan Seddon spoke to another packed audience.

Wherever you are, whatever your specialties, it’s definitely worth searching out meetups in your area that focus on your interests – especially when they’re sponsored by Web Directions, and even more especially when it’s conference time.

 

The post Idea of the Week: Ricky Onsman appeared first on Web Directions.

Monday Profile: Yoav Weiss

Source: Web Directions BlogJohn • 25 July 2016 12:30 AM

Yoav WeissThe Code conference is upon us this week! Monday Profile is again with one of our international speakers, Yoav Weiss.

Yoav is a Web performance and browser internals specialist, whose talk at Code focuses on third party content on websites, mitigating its impact on performance and security, and its longer term implications.

This interview is also in the second issue of our Scroll Magazine.

Q What made you decide you could do this for a living?

A I grew up in Israel where software development is the major industry. So, before I started higher education, I decided to work for a while to save up some money that would help me get myself through school. With software being the major (if not only) non-minimum-wage option, I started working as a software tester, picked up programming while doing that, and moved to software development a few weeks later.

I found it to be extremely fun and creative and I loved the problem solving part of it. Before I knew it, I was deep in the trenches in a software engineer position.

Took me few more years to actually take some time off in order to go to school and complete a Computer Science B.Sc.

Q Have you ever coded live on stage, or in front of an audience? How did it go?

A No, I have not. I don’t think that my typing skills are up for the task. If I had to demonstrate code on stage, I’d probably use a pre-recorded video.

Q How do you further develop and extend your skills? Books, courses? Noodling by yourself?

A I read professional books from time to time, but most of my reading is done online. A large chunk of my work day (and evenings) is dedicated to reading the latest blog posts, standards discussions and specification changes. Whenever I encounter a new subject that I need to study, I usually tackle it with a mix of tutorial reading and playing around with it in practice.

Q Is it better to learn HTML then CSS then JavaScript, or JavaScript then HTML then CSS, or all three at once, or something else?

A HTML is the foundation upon which the web is built, and it’s certainly not advised to reimplement basic HTML functionality in JavaScript. So, if your job is to build Web pages, you probably want to learn the foundations first, starting from HTML, then CSS and then JavaScript.

That way you can be sure that you’re tackling the problems you encounter with the right tools for the job, creating page components with HTML, styling them with CSS and adding functionality on top of that using JavaScript.

Q What’s the best way to get more women coding?

A I think the real question is how do we avoid discouraging the women and other under-represented groups about to enter the field from feeling marginalized and unwelcome. To me, the key is to create welcoming and “noob-friendly” environments. Many projects use the “meritocracy” narrative in order to justify shitty behaviour to people new to the project, or to people in general.

That behaviour is particularly hostile to women and other under-represented groups, but at the end of the day, it’s bad for everyone. No-one likes to have to take verbal abuse as part of their work, and certainly not as part of their off-hours open source participation.

I believe that a code of conduct with clear rules regarding unacceptable behaviour and strict enforcement of those rules helps everyone, enables everyone to express themselves, and encourages new people of all kinds to participate.

Q Frameworks. What’s your take? Are they good, bad or does it depend on how you use them?

A Frameworks help speed up development and have certain UX advantages, but they often do that at the expense of our users. Our users often have to run more code on their machines than necessary, which can be taxing for both loading and runtime performance. Especially today, when more and more of our users are on mobile devices, the performance price of frameworks must be taken into account when deciding to use them.

At the same time, the wide use and popularity of frameworks indicates that there’s a need for the abstraction they provide. As someone working on browsers and the Web platform, I give a lot of thought to that subject. I’m hoping that one day we can figure out a way to provide the UX and development ease of frameworks as part of the platform itself.

Q Tabs or spaces?

A Vim.

Q What’s on your horizon?

A I plan to continue working on browsers and their performance-related features, at least until I feel that loading performance is no longer an issue. I don’t think that will happen anytime soon :)

Another issue that’s close to my heart is getting more people involved in Web standards and browser work, which is why I took on co-chairing the Web Platform Incubation Community Group (or WICG for short). So I intend to continue to do what I can in order to make “getting involved” as painless a process as possible.


Like to watch and read more like this? Be the first to score invitations to our events? Then jump on our once a week mailing list where we round up the week’s best reading and watching on all things Web. And you’ll get a complimentary digital copy of our Scroll magazine.


The post Monday Profile: Yoav Weiss appeared first on Web Directions.

Video of the Week–Jen Simmons: Real Art Direction on the Web

Source: Web Directions Blog John • 21 July 2016 11:57 PM

At Respond this year, Jen Simmons gave a very well received session on the current state of CSS layout. A great deal is now possible that never has been before with flexbox, and even more is in the pipeline with Grid layouts.

We finally have the tools necessary to create amazing page designs on the web. Now we can art direct our layouts, leveraging the power and tradition of graphic design. In this eye-opening talk, Jen explores concrete examples of an incredible range of new possibilities.

She walks through a step-by-step design process for figuring out how to create a layout as unique as your content. You’ll learn how Flexbox, Grid, Shapes, Multicolumn, Viewport Units, and more can be combined together to revolutionize how you approach the page — any page.

Get more like this delivered weekly

Like to watch and read more like this? Be the first to score invitations to our events? Then jump on our once a week mailing list where we round up the week’s best reading and watching on all things Web. And you’ll get a complimentary digital copy of our brand new magazine, Scroll.


The post Video of the Week–Jen Simmons: Real Art Direction on the Web appeared first on Web Directions.

Minutes Telecon 2016-07-20

Source: CSS WG Blog Dael Jackson • 21 July 2016 12:22 AM

Full Minutes

Video Ristretto: Rhiana Heath–Pop-up Accessibility

Source: Web Directions BlogJohn • 20 July 2016 03:09 AM

Modals and pop-ups can be a really useful tool for displaying additional information or getting users to enter information in a way that doesn’t clutter up your screen. However as yet (one coming soon) there is no official HTML element that lets us display modals in a consistent way. As a result screen readers, such as JAWS and NVDA, have a hard time reading them resulting in a lot of pop-ups not being accessible to people with disabilities.
In this week’s video ristretto, Rhiana Heath looks at how to make modals accessible for people who use screen readers. This uses a combination of ARIA attributes and hidden text to speak with the screen reader. As well as helping of JavaScript to help with some custom keyboard control. All while keeping a pleasing look and feel for all users using JavaScript and CSS.

Want more?

Like to see and read more like this? Be the first to score invitations to our events? Then jump on our once-a-week mailing list where we round up the week’s best reading and watching on all things Web. And you’ll get a complimentary digital copy of our brand new magazine, Scroll.


The post Video Ristretto: Rhiana Heath–Pop-up Accessibility appeared first on Web Directions.

Monday Profile: Rachel Andrew

Source: Web Directions BlogJohn • 18 July 2016 02:19 AM

Rachel AndrewMonday Profile today again shares an interview we conducted with a Code conference speaker.

You’ll find all these interviews (and a lot more!) in the second issue of our Scroll Magazine.

This week, it’s with Rachel Andrew, whose talk and workshop on CSS Grid Layouts should be a conference highlight.

Rachel Andrew: In Person

Q What made you decide you could do this for a living?

A Despite being the daughter of a programmer, I had no intention of working with computers. I trained in dance and music theatre and I was convinced that my future lay in the theatre somewhere. Life had different ideas and I began building websites when pregnant with my daughter in late 1996. By the time she was three years old I was proficient enough to be offered a job in a dot com company. I’m curious about how things work and not afraid to play, experiment and get things wrong. That, coupled with an ability for unpicking complex problems, has made up for my lack of formal training in computer science – though I sometimes find myself searching for the definition of something that everyone else seems to know already!

The web is a great place to work for the polymath. Most of us aren’t sitting in cubicles working on small parts of systems – we get to build large chunks, sometimes even entire experiences. I love that there is always something new to learn and it might be in a completely different area to the last thing I studied.

Q Have you ever coded live on stage, or in front of an audience? How did it go?

A I’m not a fan of live coding in presentations, unless the presenter is truly exceptional at it. There are a few people who really have this skill, however much live coding results in fumbling through examples – often with the audience yelling out corrections to the presenter’s typos! In presentations of an hour or less I prefer to have my code on slides, that I can then talk about. I often link to fully worked examples for the audience to take a look at later. This approach lets me craft a talk of the right length that hits the things I want to share with the audience.

In my day-long workshops I do live code, however I begin with a set of starting point files on CodePen, and we work together to build out the examples. I try to keep the typing to the minimum required to show the techniques – partly to focus on what we are learning but partly for self-preservation. Three years ago I shattered my elbow and have about 30% use of my dominant hand. Typing all day is pretty difficult for me, so I try and keep the examples streamlined.

Q How do you further develop and extend your skills? Books, courses? Noodling by yourself?

A I attend a lot of conferences, I enjoy seeing talks that are on areas I don’t do so much myself. I’m a developer, so it is interesting to sit in on a design talk; I’m not someone who uses JavaScript frameworks such as React, so it is interesting to sit in on a React or Angular talk. I find different approaches make me think about the things I do in a different way.

In terms of CSS, I mostly learn by reading the specifications and building examples. Even where no browser implementation exists, I’ll usually build examples just to clarify how it is supposed to work in my own mind. That is where a lot of my work on CSS Grid started – I was building examples of something that didn’t yet exist in any browser and then as implementations appeared I could see if what I thought was the case, actually worked!

Q Is it better to learn HTML then CSS then JavaScript, or JavaScript then HTML then CSS, or all three at once, or something else?

A HTML and CSS, then JavaScript. You need to understand the DOM and the presentation layer that is CSS before you start using JavaScript to manipulate it. In addition, there is so much now that is part of CSS that traditionally we would have had to use JavaScript for – it is worth making sure that you aren’t using JavaScript for something we have a perfectly useful CSS property for.

Q What’s the best way to get more women coding?

A I’m not sure I have a good answer to that, however I mentioned that my father is a programmer. He was a programmer all through my childhood and worked at Newcastle University in the UK. We would sometimes go visit him at the computing lab, and there I took away the impression that programmers were mostly women. It was women I spoke to, sat amongst the giant whirring computers. It never occurred to me that this wasn’t a job for someone like me.

I think having role models who represent the different reasons why people get into this field has to be a positive thing. Some people are genuinely interested in code, in and of itself. Others are perhaps more interested in running a business, creating products – and writing code is just the route to being able to do that. For young people to see that is I think important, and as important for young men as well as young women.

Q Frameworks. What’s your take? Are they good, bad or does it depend on how you use them?

A It absolutely depends on how you use them, that is the same for any tool. I would encourage anyone who wants to work as a professional in this business to learn HTML and CSS, understand the basics of Accessibility, and also learn a solid amount of vanilla JavaScript. The reason being that these languages and principles are pretty timeless. They will outlast your understanding of the framework of the moment, and they will enable you to make good decisions about frameworks rather than being swayed by what everyone on Twitter is saying.

From that point, you need to look at the business requirements for the thing you are building. How much time have you available? What are the upsides of using a framework, what are the downsides? Does one outweigh the other? You can usually fairly easily make those decisions, and then be in a good position to address any potential downsides with your choice.

My real concern with frameworks is that a complete reliance on tools and frameworks is creating abstractions to the extent that people are unable to engage with the underlying languages. This means they struggle to debug issues, as they don’t understand how to create a reduced test case without the involvement of the tool. It also means that they don’t butt up against places where our core specifications are lacking. I’d love for more people to be looking at the CSS specs for example and asking “why can’t we do x?” If folk are always working with an abstraction they are less likely to do that, instead just working with what their favourite tool gives them.

Q Tabs or spaces?

A I really don’t care. Be consistent with the rest of your team. There are better things to worry about.

Q What’s on your horizon?

A A lot of travel! I’m speaking at several conferences about Grid Layout and related CSS specifications. We’ve also got a bunch of exciting things planned for my CMS product Perch and Perch Runway. Lots to do – but I like it that way!


Like to watch and read more like this? Be the first to score invitations to our events? Then jump on our once a week mailing list where we round up the week’s best reading and watching on all things Web. And you’ll get a complimentary digital copy of our Scroll magazine.


The post Monday Profile: Rachel Andrew appeared first on Web Directions.

Minutes Telecon 2016-07-13

Source: CSS WG Blog Dael Jackson • 14 July 2016 01:02 AM

Full Minutes

Ilya Streltsyn (Russian: Илья Стрельцын) collects surprising…

Source: W3C's Cascading Style Sheets home page12 July 2016 12:00 AM

12 Jul 2016 Ilya Streltsyn (Russian: Илья Стрельцын) collects surprising, but beautiful things people do with CSS. (He has similar examples for SVG and JavaScript.) The page is in Russian, but just follow the links from the pretty pictures, or use Google's translation.

Feeds

The Future of Style features:

If you have a post you want to add to this feed, post a link (or the whole thing) on the CSS3 Soapbox. If you own a blog with frequent posts about the future of CSS, and want to be added to this aggregator, please get in touch with fantasai.

fantasai

Made with CSS! Valid CSS!Valid HTML 4.0! RSS feed Atom feed