https://wiki.mozilla.org/api.php?action=feedcontributions&user=Fantasai&feedformat=atomMozillaWiki - User contributions [en]2024-03-29T01:48:27ZUser contributionsMediaWiki 1.27.4https://wiki.mozilla.org/index.php?title=Summit2008/Notes/Identity_Transcript&diff=756324Summit2008/Notes/Identity Transcript2013-11-09T03:02:22Z<p>Fantasai: format</p>
<hr />
<div><pre><br />
--- Log opened Wed Jul 30 23:53:10 2008<br />
Mitchell: Plan to spend 10-15 min on question of Mozilla Identity<br />
Mitchell: Look at stuff on flip charts, get an idea of where they fit,<br />
how do they fit<br />
Mitchell: ... discuss proposed goals<br />
Mitchell: I went through this tree. Didn't get any horrendous feedback<br />
saying it's wrong<br />
<br />
Mitchell: Things coming up lately, couple things that need to be represented<br />
that aren't<br />
Mitchell: One, community<br />
Mitchell: It flows through everything we do. In one sense it's implicit<br />
in that, in one sense it's missing.<br />
Mitchell: So how do we represent the idea of community in that?<br />
Mitchell: Do we consider it integral in every cell that we don't need to<br />
call it out, or does it need to be called out<br />
<br />
Mitchell: Second thing is that the values from Manifesto aren't expressed<br />
in that diagram<br />
Mitchell: I'm not sure where they'd show up or how<br />
Mitchell: If they're roots, or if public benefit root picks them up<br />
Mitchell: But they are part of how we think about ourselves<br />
Mitchell: e.g. is privacy a root, since it's something we value<br />
<br />
David Ascher: One thing about community that's interesting is everybody<br />
uses the word to mean the different things<br />
David: I never use it in the singular<br />
David: People belong to Mozilla community, but also other communities.<br />
E.g. qa community, l10n community<br />
David: In these people know each other intimately<br />
David: Not like Mozilla community of 1/2 mill<br />
David: Community is interesting, but also a loaded term<br />
fantasai: maybe think of it as veins that run through the tree?<br />
Zak: ....<br />
Zak: When ppl talk about community, they're talking about peers<br />
Zak: people who are working on the same project, even remotely<br />
Zak: How many people think of users as part of community?<br />
some raised hands<br />
<br />
Mitchell: .. goals and improving interaction is connection between different<br />
parts of Mozilla<br />
Mitchell: support working w/qa<br />
e.g<br />
<br />
David: One that's challenging about scale of Mozilla at this point<br />
David: I don't think humans are evolved to work with this many people<br />
David: Hard to be in contact with thousands of people<br />
David: Our brains are not wired for that<br />
David: .. healthy relationships at scale<br />
David: So not everybody needs to know everybody else<br />
<br />
Atul: Question around who to trust around world of the Internet<br />
Atul: A lot of users coming to Internet know noting about it<br />
Atul: Interesting discussions about security. Users tend to assume that<br />
anywhere on the Internet is dangerous<br />
Atul: In reality, I only visit a subset of the Internet that I consider to be safe<br />
Atul: I will only choose to share my personal info with a small amount of that<br />
Atul: Goes into things like kind of software you download<br />
Atul: Firefox is a gateway to everything you put on your computer to some extent.<br />
Atul: How do you trust<br />
Atul: How do you know who/what to trust on the Internet.<br />
Atul: There's no real sense of identity built on the Internet.<br />
Atul: One thing I think about is doing something, something social. Social<br />
network so that my parents could say I trust my son, things that he<br />
does...<br />
Mitchell: You're talking about a more abstract concept of community<br />
Mitchell: A community of trust. A layer that is really different ...<br />
Mitchell: I can't figure out livechat<br />
(...?)<br />
Mitchell: Interesting set of identity, hard to represent as communities<br />
get more abstract<br />
<br />
Zak: If we had this biological model of what we are.<br />
Zak: Community is what we create, but also what we need.<br />
Zak: Same thing with values in manifest.<br />
Zak: Like we're trying to create the environment that we need<br />
Zak: create what's in the manifesto<br />
Zak: It's kinda like plants. They slowly changed the earth to be what they<br />
want it to be.<br />
<br />
Nicolas: It might be useful to separate community out into a noun and a verb<br />
Nicolas: The tree, you can almost put a title that says "The Mozilla Community"<br />
<br />
Nicolas: One of the roots of the community, one of the shared practices,<br />
is about a community approach.<br />
Nicolas: About less hierarchical, about creating communities<br />
Nicolas: Community is a practice that Mozilla encourages.<br />
Nicolas: I think the practice of doing community is something, and the<br />
end result is the Mozilla Community<br />
<br />
Gandalf: There's a term for that, a participatory approach.<br />
Gandalf: You can look at hierarchical org or participatory org<br />
Gandalf: We're definitely a participatory org. Empowering participating<br />
approach<br />
Gandalf: I would stake community as a noun<br />
Gandalf: And participation as a verb<br />
Gandalf: It's hard enough to define ...<br />
Gandalf: Like David said, we have trouble remembering this many people<br />
Gandalf: You're in one hundred communities of two hundred million people<br />
Gandalf: you're in community of 200,000,000 ppl using FF<br />
<br />
David: I look at this picture and I completely understand it from my position,<br />
I know how pieces fit together<br />
David: I look back to several years ago to when I was a community member<br />
David: with a different day job<br />
David: and trying to figure where I fit there, is a little interesting<br />
David: I think the roots are why I cared about Mozilla before I was really<br />
involved<br />
David: but other parts are not so relevant<br />
David: ....<br />
David: consumer products which are very focused on some smaller set of people<br />
David: If you're not close into Mozilla, which part of Mozilla are relevant<br />
to you are fuzzy and hard<br />
<br />
Mitchell: So I'd take from that naming the whole thing The Mozilla Community<br />
isn't quite right<br />
Mitchell: This leads me to think .. don't really have a clear vision of<br />
how this fits into community<br />
Mitchell: .. find it useful, but don't know how to merge it into that.<br />
Mitchell: either don't know how to visualize it in there, or maybe it's<br />
something else<br />
Gerv: Is there a correlation between the tree and the concentric circles<br />
of community?<br />
Gerv: E.g. ppl who are deeply involved, check into cvs, are an inner circle.<br />
people who use our code are an outer circle<br />
Gerv: The further out you go, the less the values in the roots are deeply held<br />
?: It seems like there does need to be a place somewhere there.<br />
?: Mozilla communities- you don't need to fit into and participate in all<br />
the branches to be part of it<br />
?: I like the idea that we could label the whole metaphor community<br />
Guillermo: It's difficult to draw the concentric cirlces in the same image<br />
Guillermo: Maybe the tree rings<br />
Mitchell: I'm inclined to take these ideas back and see if we can merge them<br />
Mitchell: Or if we should keep them separate for awhile<br />
<br />
bsmedberg: I don't think the community belongs on that tree<br />
bsmedberg: I think shared goals or shared something define the community<br />
bsmedberg: but if you come up with the shared whatever we are, the community<br />
flows from that<br />
bsmedberg: saying that we are a community without having the shared goals<br />
is backwards to me<br />
<br />
Tiffney: I think we're going with this metaphor you can look as community<br />
as ecosystem<br />
Tiffney: You can't dissect the ecosystem from that picture<br />
summary of her comments: Community as ecosystem<br />
<br />
Zak: I can't figure out what other community from history we're like?<br />
Zak: There's no form to fill out, no creed. Maybe that's why we're confused<br />
as to what we are<br />
Gerv: The reason that's been possible is the zero-incremental cost of<br />
copying softare<br />
Gerv: 20 years ago nobody could reach 200 mill people with useful stuff<br />
<br />
Mitchell: the other thing that came up a lot is values<br />
Mitchell: Manifesto values, that don't overtly show up in that<br />
Mitchell: We could try to distill a few of them, and make them roots or<br />
branches or something<br />
Mitchell: One term I want to use, although it's overloaded, is user sovereignty<br />
Mitchell: Any thoughts?<br />
David: You could just point to manifest, or say manifesto values<br />
David: Manifesto describes a lot of values<br />
David: ... I hate to use the word morals<br />
David: there are some sort of moral underpinnings that drive ...<br />
<br />
fantasai: So what I'm seeing here is that the values in the roots are how<br />
we operate, and the values in the manifesto are things we value<br />
and want to create<br />
<br />
Mark: ....<br />
Mark: Thinking about where to put the values. We haven't used the leaves<br />
at all. There's unused real estate in the leaves<br />
Gerv: The tree starts small and grows more<br />
Gerv: So maybe the values are suspended in the air, what we're aiming up<br />
<br />
Eric: Talking about community, and ecosystem. A forest of trees would<br />
represent our user base or community<br />
Eric: Maybe show that our interest is civic benefit of the forest<br />
<br />
Blizzard(?): If you're very far from trees they look very different from up<br />
close<br />
Blizzard(?): Something to think about<br />
Zak: Also some people see trees as lumber<br />
Zach(?): I feel the values belong at the roots, and maybe those attributes<br />
of Mozilla are something that belong as clouds<br />
Zach(?): Raining down and enriching the growth of the tree<br />
fantasai: I don't think that matches, the roots really anchor this<br />
project/community<br />
<br />
Mitchell: One thing that's different about Mozilla is our focus on producing<br />
a product rather than being an advocacy organization<br />
<br />
Gandalf: I was thinking about what zak said, part of us considers users<br />
part of community or community itself, and others don't<br />
Gandalf: It would be a good idea to claim that the community is made up<br />
of people who consider themselves part of community<br />
Gandalf: So ppl who use product and consider themselves part of community<br />
are, and those who don't aren't<br />
Gandalf: It's a very open community<br />
Gandalf: anyone can decide to participate<br />
Mitchell: So you'd have a user base that was important to our effectiveness,<br />
but you wouldn't consider part of the community<br />
simon: ...<br />
simon: every little bit that you do, besides downloading thu/ff and<br />
installing it<br />
simon: things you do like telling your friend, this solftware is great you<br />
should use it<br />
simon: or publishing a holiday calendar for sunbird<br />
simon: that makes you part of the community, whether you consider yourself<br />
part of the community or not<br />
Mitchell: We have a difference of opinion of whether we consider the user<br />
base part of the community or not<br />
Mitchell: we should be clear that it's different from other communities<br />
<br />
?: Going back to Zak's point, .. distinguishes use from other kinds of<br />
nonprofits. Every effective nonprofit chooses a strategy.<br />
?: E.g. EFF chose lawsuits as it's approach.<br />
Brian: We do have advocacy around a certain set of positions<br />
Brian: Our strategy is around a free product<br />
Brian: Because everyone would be tied to MS if there wasn't an alternative.<br />
Brian: We get user power from 1.0 launch onwards<br />
Brian: The balls in our court to define that. How much are users a group<br />
that we want to involve?<br />
<br />
Mitchell: So we have some question of whether roots are roots or values<br />
are roots<br />
Mitchell: Any other thoughts on this?<br />
Mtichell: there was use real estate of leaves<br />
<br />
??: I don't know where values go on the tree<br />
??: ... people are here not because they care about making good products,<br />
but also they care about advancing values through these products.<br />
??: the values are our goal<br />
??: it's absolutely central, and the purpose of the products is to achieve<br />
that<br />
Mitchell: So I think values is the trunk.<br />
Mitchell: It currently says human interaction with internet<br />
Mitchell: but it's a certain type of interaction that we're dealing with<br />
<br />
Asa: We talk about values. We're not just advancing them, we're inventing them.<br />
Asa: We're inventing values for a new world on the net. It didn't used<br />
to have this value landscape.<br />
Asa: Tricky, because we're both advancing them and creating them<br />
Asa: both in terms of defining them, but also in creating them through<br />
products that advance those values<br />
Asa: I feel like our products are the embodiment of our values.<br />
Asa: We invented the values, then invented products to make them real<br />
<br />
Asa: It really is the bark that's over the whole tree<br />
Asa: Same way that community and participation are<br />
Asa: We aren't participation because it's useful, but because we believe<br />
it's integral to the web<br />
Asa: For those two in particular, I'm opposed to making it an appendage<br />
Asa: They feel more like circulatory system.<br />
<br />
Zach: Where does innovation fit into this? We have this shared bias towards<br />
innovation, show me the code.<br />
???: The roots feel like methods<br />
Mitchell: This would be a question, maybe it's historical<br />
Mitchell: My sense is that those methods are deep enough to be a sense of<br />
identity<br />
Mitchell: I think if you ask the people here, if you could create something<br />
that doesn't have that, wouldn't identify as Mozilla<br />
<br />
Gerv: So we can pull this tree metaphor every which way.<br />
Gerv: leaving aside the tree.<br />
Gerv: Things come out of your values via your methods to produce results<br />
Gerv: I don't think the participatory web is a result<br />
Gerv: It's a means to an end which is whatever the people participating<br />
get out of it<br />
Gerv: If that were true, perhaps the roots are the values, the trunk are<br />
the things that are the things in the trunk<br />
Gerv: and what we make are the fruits<br />
Gerv: Maybe we need to step back away from the tree and think how they<br />
fit together, then put them back on the tree<br />
Guillermo: Maybe the values could be the ... the liquid inside the tree.<br />
The sap.<br />
<br />
Mitchell: So 2 proposals for changing tree<br />
Mitchell: question of how we work<br />
Mitchell: We're not going to use public benefit, shared asset, to get to<br />
the web would we still feel like Mozilla<br />
<br />
Mark: Theres a guy who put out a book called Two Bits, where he looked as<br />
open source movement<br />
Mark: He says that what's different from other social movements<br />
mark: Is that the values and the practices are embedded in each other<br />
mark: not just advocating values<br />
Mark: You kinda have to keep them, they're together<br />
Mark: they're in the roots is right<br />
<br />
Mitchell: Want to talk a bit about goals<br />
Look through bunch of stuff on goals<br />
Mitchell: Weren't a lot of comments saying this is a terrible goal, take<br />
it off<br />
Mitchell: where we've got so far<br />
Mitchell: Firefox should continue, momentum, agreement there<br />
Mitchell: Not much comments on Mobile saying no. Most comments are why not<br />
already and here's how to do it<br />
<br />
Mitchell: Two things are data and information<br />
Mitchell: potentially most divisive<br />
Mitchell: Mozilla and open Internet has another large set of ideas<br />
Mitchell: Just want to call out what came out from open Internet<br />
Mitchell: then talk about data<br />
Mitchell: For Mozilla as open Internet and Mozilla as community<br />
Mitchell: Some education and evangelism function, both internally and<br />
externally<br />
<br />
Mitchell: Internal ones captured best as<br />
Mitchell: There's some way that Mozilla communities grow. Some ways that<br />
knowledge is implicit, but we don't make it explicit<br />
Mitchell: Example, small l10n team. How do you grow that team?<br />
Mitchell: We've done it tons of time, but there's no set of steps<br />
Mitchell: So there's no understood way to do it<br />
Mitchell: we do it well, but it's very ad-hoc<br />
Mitchell: e.g. I found my way in, but I don't know how I did it, and I<br />
don't know how to help someone else<br />
Mitchell: Very strong interest in figuring out how to be clear on what<br />
entry paths work, what are experiences are and how to use them.<br />
Mitchell: We know a lot of things<br />
Mitchell: about scale, l10n, upgrades, etc.<br />
Mitchell: What's path for Mozilla to spread that knowledge to those who<br />
want it?<br />
mitchell: reluctant to have too long list of goals, but that seems like<br />
something that should show up more explicitly<br />
<br />
Mitchell: Other thing ins emphasis on content. encourage open content<br />
creation on the Internet<br />
Mitchell: I'd put them as a center piece of the open web or open Internet<br />
Mitchell: Tools we should think about and think hard how to do them.<br />
Mitchell: Anything else missing?<br />
<br />
David: I like part about teaching the knowledge and skills that Mozilla<br />
has earned to outside<br />
David: Flip side is we only get to open Internet by collaborating with others<br />
David: one thing I try to figure out is how do we effectively learn from<br />
others, not just tell them this is what works?<br />
Mitchell: so learning to collaborate and inward-bound learning<br />
<br />
Gerv: On content creation piece<br />
Gerv: Mark made a good point about content creation<br />
Gerv: The project we are is composed of seamonkey, effectively<br />
Gerv: How do you create content for the web has changed a lot since days<br />
of NS4<br />
Gerv: Nowadays ppl wanting to put thoughts on web, just get a blog.<br />
Gerv: People that do more than that do ajax-based interactive websites<br />
Gerv: In one sense the content creation part is done.<br />
Gerv: blogs, cms, wiki<br />
Gerv: Or we're not done.<br />
Gerv: Do we make tools for putting content on the web?<br />
<br />
Mitchell: Looks like Travel is taking over here<br />
????: Last comments on where it goes and how to continue discussion?<br />
Mitchell: What are good ways to continue this conversation? Clearly not<br />
my blog?<br />
Mitchell: I'm the leader for this particular set of discussions.<br />
Mitchell: if nothing else send it to me<br />
Zak: Wiki?<br />
simon: .. blog<br />
Gerv: good thing about newsgroup is that it's newsgroup, mailing list,<br />
google group, rrs<br />
Mitchell: Will send mail to summit alias<br />
Mitchell: I do have a blog, do send comments :)<br />
<br />
ctalbert: I was at OSCON last week<br />
ctalbert: One session from Intel was talking about three challenges on Internet<br />
ctalbert: And one challenge was data.<br />
ctalbert: and how Intel can help you integrate data on the net<br />
ctalbert: that made my skin crawl<br />
Mitchell: the ... is not privacy for each person<br />
Mitchell: My ability to protect my data when I want to, that's Foundation step<br />
Mitchell: Problem is most of you, most of us, will trade personal data for<br />
convenience and features<br />
Mitchell: We're all making those trades<br />
Mitchell And the conceptual issue is that most consumers want some data<br />
to be shared.<br />
MtichelL: and different people make different trades for how much data<br />
for how much free stuff<br />
Mitchell: A lot of consumers want things very different<br />
Mitchell: Of course you can keep data private and not share.<br />
Mitchell: But when you want websites to use data for some things, that's hard<br />
Blizzard: One thing I learned with project I did was vast difference in<br />
expectations of privacy<br />
Blizzard: experience from all over spectrum<br />
blizzard: there's no common language. People don't even know how to think<br />
about it<br />
blizzard: we need to define that language, give them a way to talk about it<br />
blizzard: seems that education function has to be the first step<br />
blizzard: esp outside our space where we've thought about it<br />
blizzard: coming up with framework would be important<br />
Mitchell: Another set of posts lacking comments...<br />
<br />
Zak: I think Tiffney really nailed it when she called it an ecosystem.<br />
Zak: our ecosystem is thriving <br />
Zak: we care about our values, most people using firefox don't know and<br />
don't care<br />
Zak: the more we provide value, the more we get a chance to explain to them<br />
about privacy<br />
zak: our product is our vehicle for our values<br />
<br />
Mitchell: Advocating privacy and building a product that that allows it<br />
is different<br />
Mitchell: there's an advocacy piece<br />
Mitchell: but I'm interested in building a product that actually protects<br />
privacy<br />
Asa: We can't convince the world that it matters, but we can build a product<br />
that does it, that has features that allows people to manage their data<br />
in a way that protects it<br />
....<br />
Meeting usurped by Lilly<br />
</pre></div>Fantasaihttps://wiki.mozilla.org/index.php?title=Platform/Features/Vertical_text&diff=659998Platform/Features/Vertical text2013-05-24T08:24:02Z<p>Fantasai: </p>
<hr />
<div>{{FeatureStatus<br />
|Feature name=Vertical text<br />
|Feature stage=Draft<br />
|Feature health=OK<br />
}}<br />
{{FeatureTeam<br />
|Feature product manager=Jet Villegas<br />
|Feature lead engineer=Simon Montagu<br />
|Feature dev engineer=Simon Montagu<br />
}}<br />
{{FeaturePageBody<br />
|Feature open issues and risks=Specification is in flux.<br />
|Feature overview=Add support for vertical text layout.<br />
<br />
Text for most scripts on the web today are laid out horizontally. <br />
However, Japanese, Chinese and to some degree Korean can also be laid<br />
out vertically. When laid out vertically, these languages use<br />
top-to-bottom, right-to-left flows. Classical Mongolian is generally<br />
considered a "vertical only" language, although in multi-script<br />
contexts it can also be drawn horizontally. Mongolian, along with<br />
Phags-pa flows top-to-bottom, left-to-right. Western text such as<br />
Latin, Greek and Cyrillic can also be displayed vertically, examples<br />
of this often appear on book spines and in signage.<br />
|Feature users and use cases=Users: publishers of vertically typeset content (e-publishing organisations, independent web authors, especially in East Asia)<br />
<br />
Example use cases:<br />
* Web-based e-readers for Japanese novels (especially on mobile devices)<br />
* Web pages that use classical Mongolian script<br />
|Feature requirements=* Support vertical text for whole documents (i.e. initial containing block uses a vertical writing mode) and document fragments (i.e. orthogonal flows)<br />
* Support both top-to-bottom, right-to-left (e.g. CJK) and top-to-bottom, left-to-right (e.g. Mongolian) writing modes.<br />
* As far as possible (particularly given that the spec is in flux), conform to the relevant parts of [http://dev.w3.org/csswg/css3-writing-modes/ CSS3 Writing Modes specification]&mdash;most likely the <code>writing-mode</code> and <code>text-orientation</code> properties.<br />
|Feature non-goals=* Support ''all'' of the [http://dev.w3.org/csswg/css3-writing-modes/ CSS Writing Modes specification]<br />
** For example, properties such as <code>unicode-bidi</code>, <code>text-combine-horizontal</code>, and <code>text-combine-mode</code> are probably outside the scope of this feature<br />
* Support [https://bugzilla.mozilla.org/show_bug.cgi?id=33339 HTML ruby]<br />
* Support vertical text in SVG<br />
|Feature functional spec=* Bug 0 - Prototype<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=772321 Bug 1] - Parse writing mode and text-orientation<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=735577 Bug 2] - Logicalize Reflow APIs<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=789096 Bug 3] - Logicalize Reflow for all frame classes<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=649142 Bug 4] - Refactor and extend logical CSS properties<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=789099 Bug 4] - Orthogonal Flows<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=789103 Bug 5] - UI<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=789104 Bug 6] - Text/Glyph Layout<br />
|Feature implementation plan=* Prototype of a vertical text layout. This will include:<br />
** logicalization of a minimum of frame types<br />
** layout of a minimum of frame types<br />
** Glyph layout of CJK only<br />
** Parsing, orthogonal flows and UI will not be included<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=772321 Bug 2]: Parsing of <code>writing-mode</code> and <code>text-orientation</code><br>(see [[#9._Implementation|Implementation]] below)<br />
<br />
The above is done. Steps to implement (parallelizable steps preceded by --> to indicate possible forking-off):<br />
<br />
* --> [https://bugzilla.mozilla.org/show_bug.cgi?id=649142 Bug 4] - Refactor existing logical CSS properties<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=772321 Bug 1] - Parse writing mode and text-orientation<br />
* --> Extend logical CSS properties to handle vertical text (depends only on Bugs 1 and 4)<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=735577 Bug 2]: Logicalization of layout parameters<br />
** May involve some renaming across the layout engine, but shouldn't affect logic at this point<br />
** Note that some frame classes will continue to be physical, e.g. images, even after full logicalization<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=789096 Bug 3]: Logicalize Block and Inline layout <br />
** Logicalize nsBlockFrame. Get vertical-only/horizontal-only documents consisting of only block frames working/tested<br />
** Note that not all properties get treated the same. For example, the offset of a <code>text-shadow</code> property is unaffected by writing mode.<br />
** Logicalize nsLineLayout, nsInlineFrame, nsTextFrame, etc. Get inline layout working for vertical-only documents. Make the text just draw sideways for now.<br />
* --> After block and inline layout, other frame classes can be converted set by set, e.g.<br />
** Tables<br />
** Flexbox<br />
** etc.<br />
* --> [https://bugzilla.mozilla.org/show_bug.cgi?id=789099 Bug 4]: Orthogonal flows<br />
** Probably requires a lot of rework of intrinsic sizing. This is a complicated task!<br />
* --> [https://bugzilla.mozilla.org/show_bug.cgi?id=789103 Bug 5]: UI features<br />
** scrollbars<br />
** mapping scrollwheel<br />
** vertical text selection<br />
** vertical text selection cursor<br />
** caret browsing<br />
** list boxes/combo boxes (initial implementation should just transform the control; next pass does actual vertical layout)<br />
** menus<br />
** other?<br />
* --> [https://bugzilla.mozilla.org/show_bug.cgi?id=789104 Bug 6]: Glyph orientation<br />
** Using character properties such as those defined in [http://www.unicode.org/reports/tr50/ UTR-50] (currently under review)<br />
** Supporting different modes as necessary (e.g. stacked vs default, cf. <code>text-orientation</code> which is in flux)<br />
** Glyph selection&mdash;choosing vertical variants, using vertical metrics<br />
** OpenType model for vertical text needs to be flushed out a bit more (e.g. which features are on by default in the vertical case?)<br />
|Feature implementation notes=[https://bugzilla.mozilla.org/show_bug.cgi?id=145503 Main bugzilla entry]<br />
<br />
* Need to investigate how to pref CSS keyword parsing (and all writing-mode processing) on and off. (This is relatively straightforward, now that {{bug|753522}} is implemented. Just specify the pref in the property's chunk of nsCSSPropList.h, and use Preferences::GetBool() elsewhere if necessary.)<br />
* Possibly want to be able to <code>#ifdef</code> it as well? Or just back out the changes after each uplift so we don't pay the perf cost until it's ready? [There shouldn't be any perf cost.]<br />
<br />
* Multi-column vertical layout<br />
* Form controls<br />
* Tables<br />
* (Probably lots of other HTML elements that require special handling? e.g. list markers. Presumably images don't rotate (i.e. width/height are physical) but form controls do?)<br />
* Pagination<br />
* Implement <code>min/max/fit-content</code>, <code>fill-available</code><br />
}}<br />
{{FeatureInfo<br />
|Feature priority=Unprioritized<br />
|Feature roadmap=Platform<br />
|Feature engineering team=Layout<br />
}}<br />
{{FeatureTeamStatus}}</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Platform/Layout/CSS/CSSWG_Priorities_2012&diff=470182Platform/Layout/CSS/CSSWG Priorities 20122012-09-12T22:15:05Z<p>Fantasai: factor in dbaron's input</p>
<hr />
<div>= CSSWG Priorities 2012 =<br />
<br />
Our opinions on what those priorities should be.<br />
<br />
== Key ==<br />
<br />
"very strong interest" (VSI), "strong interest" (SI), "low interest" (LI) or "not interested" (NI)<br />
<br />
== Candidate Recommendations (Testing Needed) ==<br />
<br />
{|<br />
! Priority !! Spec !! Comments<br />
|-<br />
| SI || CSS Backgrounds and Borders Module L3 || <br />
|-<br />
| VSI || CSS Flexible Box Layout Module L1 || <br />
|-<br />
| SI || CSS Image Values and Replaced Content L3 || <br />
|-<br />
| SI || CSS Multi-column Layout Module || <br />
|-<br />
| NI || CSS Speech L1 || <br />
|-<br />
| NI || CSS Style Attribute L1 || <br />
|-<br />
| SI || CSS Values and Units Module L3 || <br />
|}<br />
<br />
== CSS3 Working Drafts (Spec-work Needed) ==<br />
<br />
{|<br />
! Priority !! Spec !! Comments<br />
|-<br />
| VSI || CSS Animations L1 || <br />
|-<br />
| LI || CSS Box Model L3 || <br />
|-<br />
| SI || CSS Box Alignment Module L3 || <br />
|-<br />
| LI || CSS Color Correction || <br />
|-<br />
| VSI || CSS Conditional Rules Module L3 || <br />
|-<br />
| LI || CSS Counter Styles L3 || <br />
|-<br />
| LI || CSS Device Adaptation || <br />
|-<br />
| NI || CSS Exclusions and Shapes || <br />
|-<br />
| VSI || CSS Fonts L3 || <br />
|-<br />
| SI || CSS Fragmentation Module L3 || <br />
|-<br />
| NI || CSS GCPM || Might want to pull out some features into other modules, though<br />
|-<br />
| SI || CSS Grid Layout || <br />
|-<br />
| NI || CSS Grid Template Layout || <br />
|-<br />
| NI || CSS Hierarchies || <br />
|-<br />
| SI || CSS Intrinsic & Extrinsic Sizing Module L3 || <br />
|-<br />
| LI || CSS Line Grid Module || <br />
|-<br />
| LI || CSS Line Layout L3 || <br />
|-<br />
| LI || CSS Lists and Counters Module L3 || <br />
|-<br />
| SI || CSS Mobile Text Size Adjustment Module || <br />
|-<br />
| LI || CSS Paged Media Module L3 || <br />
|-<br />
| NI || CSS Pagination Templates Module || <br />
|-<br />
| LI || CSS Positioned Layout Module L3 || <br />
|-<br />
| SI || CSS Overflow Module || <br />
|-<br />
| NI || CSS Regions || <br />
|-<br />
| LI || CSS Ruby ||<br />
|-<br />
| LI || CSS Syntax L3 || <br />
|-<br />
| SI || CSS Text Decoration Module L3 || <br />
|-<br />
| SI || CSS Text Module L3 || <br />
|-<br />
| VSI || CSS Transforms || <br />
|-<br />
| VSI || CSS Transitions || <br />
|-<br />
| LI || CSS UI || <br />
|-<br />
| SI || CSS Writing Modes L3 || <br />
|}<br />
<br />
== CSSOM Working Drafts (Spec-work Needed) ==<br />
<br />
{|<br />
! Priority !! Spec !! Comments<br />
|-<br />
| LI || CSS OM Values Module || <br />
|-<br />
| SI || CSS OM View Module || <br />
|-<br />
| LI || CSS OM || <br />
|}<br />
<br />
== CSS4 Working Drafts (Spec-work Needed) ==<br />
<br />
{|<br />
! Priority !! Spec !! Comments<br />
|-<br />
| NI || CSS Background and Borders L4 || <br />
|-<br />
| SI || CSS Image Values and Replaced Content Module LEVEL 4 || <br />
|-<br />
| NI || CSS Pseudo-Elements L4 || <br />
|-<br />
| NI || CSS Text L4 || <br />
|-<br />
| SI || Media Queries L4 || <br />
|-<br />
| SI || Selectors L4 || Need to split the draft into L4/L5<br />
|}<br />
<br />
== FXTF Working Drafts (Spec-work Needed) ==<br />
<br />
{|<br />
! Priority !! Spec !! Comments<br />
|-<br />
| LI || Compositing and Blending ||<br />
|-<br />
| LI/SI? || Filter Effects ||<br />
|-<br />
| LI/SI? || Masking ||<br />
|-<br />
| NI || Shaders ||<br />
|}</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Platform/Layout/CSS/CSSWG_Priorities_2012&diff=470166Platform/Layout/CSS/CSSWG Priorities 20122012-09-12T21:44:56Z<p>Fantasai: /* CSSWG Priorities 2012 */</p>
<hr />
<div>= CSSWG Priorities 2012 =<br />
<br />
Our opinions on what those priorities should be.<br />
<br />
== Key ==<br />
<br />
"very strong interest" (VSI), "strong interest" (SI), "low interest" (LI) or "not interested" (NI)<br />
<br />
== Candidate Recommendations (Testing Needed) ==<br />
<br />
{|<br />
! Priority !! Spec !! Comments<br />
|-<br />
| ? || CSS Backgrounds and Borders Module L3 || <br />
|-<br />
| VSI || CSS Flexible Box Layout Module L1 || <br />
|-<br />
| SI || CSS Image Values and Replaced Content L3 || <br />
|-<br />
| SI || CSS Multi-column Layout Module || <br />
|-<br />
| NI || CSS Speech L1 || <br />
|-<br />
| NI || CSS Style Attribute L1 || <br />
|-<br />
| SI || CSS Values and Units Module L3 || <br />
|}<br />
<br />
== CSS3 Working Drafts (Spec-work Needed) ==<br />
<br />
{|<br />
! Priority !! Spec !! Comments<br />
|-<br />
| VSI || CSS Animations L1 || <br />
|-<br />
| LI || CSS Box Model L3 || <br />
|-<br />
| SI || CSS Box Alignment Module L3 || <br />
|-<br />
| LI || CSS Color Correction || <br />
|-<br />
| VSI || CSS Conditional Rules Module L3 || <br />
|-<br />
| LI || CSS Counter Styles L3 || <br />
|-<br />
| SI || CSS Device Adaptation || <br />
|-<br />
| LI || CSS Exclusions and Shapes || <br />
|-<br />
| VSI || CSS Fonts L3 || <br />
|-<br />
| VSI || CSS Fragmentation Module L3 || <br />
|-<br />
| ? || CSS GCPM || Depends on the feature<br />
|-<br />
| VSI || CSS Grid Layout || <br />
|-<br />
| ? || CSS Grid Template Layout || <br />
|-<br />
| NI || CSS Hierarchies || <br />
|-<br />
| VSI || CSS Intrinsic & Extrinsic Sizing Module L3 || <br />
|-<br />
| LI || CSS Line Grid Module || <br />
|-<br />
| LI || CSS Line Layout L3 || <br />
|-<br />
| SI || CSS Lists and Counters Module L3 || <br />
|-<br />
| SI || CSS Mobile Text Size Adjustment Module || <br />
|-<br />
| LI || CSS Paged Media Module L3 || <br />
|-<br />
| LI || CSS Pagination Templates Module || <br />
|-<br />
| LI || CSS Positioned Layout Module L3 || <br />
|-<br />
| VSI || CSS Overflow Module || <br />
|-<br />
| LI || CSS Regions || <br />
|-<br />
| LI || CSS Ruby ||<br />
|-<br />
| LI || CSS Syntax L3 || <br />
|-<br />
| VSI || CSS Text Decoration Module L3 || <br />
|-<br />
| VSI || CSS Text Module L3 || <br />
|-<br />
| VSI || CSS Transforms || <br />
|-<br />
| VSI || CSS Transitions || <br />
|-<br />
| LI || CSS UI || <br />
|-<br />
| SI || CSS Writing Modes L3 || <br />
|}<br />
<br />
== CSSOM Working Drafts (Spec-work Needed) ==<br />
<br />
{|<br />
! Priority !! Spec !! Comments<br />
|-<br />
| VSI || CSS OM Values Module || <br />
|-<br />
| VSI || CSS OM View Module || <br />
|-<br />
| VSI || CSS OM || <br />
|}<br />
<br />
== CSS4 Working Drafts (Spec-work Needed) ==<br />
<br />
{|<br />
! Priority !! Spec !! Comments<br />
|-<br />
| LI || CSS Background and Borders L4 || <br />
|-<br />
| SI || CSS Image Values and Replaced Content Module LEVEL 4 || <br />
|-<br />
| NI || CSS Pseudo-Elements L4 || <br />
|-<br />
| LI || CSS Text L4 || <br />
|-<br />
| SI || Media Queries L4 || <br />
|-<br />
| VSI || Selectors L4 || <br />
|}<br />
<br />
== FXTF Working Drafts (Spec-work Needed) ==<br />
<br />
{|<br />
! Priority !! Spec !! Comments<br />
|-<br />
| ? || Compositing and Blending ||<br />
|-<br />
| ? || Filter Effects ||<br />
|-<br />
| ? || Masking ||<br />
|-<br />
| ? || Shaders ||<br />
|}</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Platform/Layout/CSS/CSSWG_Priorities_2012&diff=470164Platform/Layout/CSS/CSSWG Priorities 20122012-09-12T21:44:12Z<p>Fantasai: first cut at filling in the priorities, pretty rough</p>
<hr />
<div>= CSSWG Priorities 2012 =<br />
<br />
== Key ==<br />
<br />
"very strong interest" (VSI), "strong interest" (SI), "low interest" (LI) or "not interested" (NI)<br />
<br />
== Candidate Recommendations (Testing Needed) ==<br />
<br />
{|<br />
! Priority !! Spec !! Comments<br />
|-<br />
| ? || CSS Backgrounds and Borders Module L3 || <br />
|-<br />
| VSI || CSS Flexible Box Layout Module L1 || <br />
|-<br />
| SI || CSS Image Values and Replaced Content L3 || <br />
|-<br />
| SI || CSS Multi-column Layout Module || <br />
|-<br />
| NI || CSS Speech L1 || <br />
|-<br />
| NI || CSS Style Attribute L1 || <br />
|-<br />
| SI || CSS Values and Units Module L3 || <br />
|}<br />
<br />
== CSS3 Working Drafts (Spec-work Needed) ==<br />
<br />
{|<br />
! Priority !! Spec !! Comments<br />
|-<br />
| VSI || CSS Animations L1 || <br />
|-<br />
| LI || CSS Box Model L3 || <br />
|-<br />
| SI || CSS Box Alignment Module L3 || <br />
|-<br />
| LI || CSS Color Correction || <br />
|-<br />
| VSI || CSS Conditional Rules Module L3 || <br />
|-<br />
| LI || CSS Counter Styles L3 || <br />
|-<br />
| SI || CSS Device Adaptation || <br />
|-<br />
| LI || CSS Exclusions and Shapes || <br />
|-<br />
| VSI || CSS Fonts L3 || <br />
|-<br />
| VSI || CSS Fragmentation Module L3 || <br />
|-<br />
| ? || CSS GCPM || Depends on the feature<br />
|-<br />
| VSI || CSS Grid Layout || <br />
|-<br />
| ? || CSS Grid Template Layout || <br />
|-<br />
| NI || CSS Hierarchies || <br />
|-<br />
| VSI || CSS Intrinsic & Extrinsic Sizing Module L3 || <br />
|-<br />
| LI || CSS Line Grid Module || <br />
|-<br />
| LI || CSS Line Layout L3 || <br />
|-<br />
| SI || CSS Lists and Counters Module L3 || <br />
|-<br />
| SI || CSS Mobile Text Size Adjustment Module || <br />
|-<br />
| LI || CSS Paged Media Module L3 || <br />
|-<br />
| LI || CSS Pagination Templates Module || <br />
|-<br />
| LI || CSS Positioned Layout Module L3 || <br />
|-<br />
| VSI || CSS Overflow Module || <br />
|-<br />
| LI || CSS Regions || <br />
|-<br />
| LI || CSS Ruby ||<br />
|-<br />
| LI || CSS Syntax L3 || <br />
|-<br />
| VSI || CSS Text Decoration Module L3 || <br />
|-<br />
| VSI || CSS Text Module L3 || <br />
|-<br />
| VSI || CSS Transforms || <br />
|-<br />
| VSI || CSS Transitions || <br />
|-<br />
| LI || CSS UI || <br />
|-<br />
| SI || CSS Writing Modes L3 || <br />
|}<br />
<br />
== CSSOM Working Drafts (Spec-work Needed) ==<br />
<br />
{|<br />
! Priority !! Spec !! Comments<br />
|-<br />
| VSI || CSS OM Values Module || <br />
|-<br />
| VSI || CSS OM View Module || <br />
|-<br />
| VSI || CSS OM || <br />
|}<br />
<br />
== CSS4 Working Drafts (Spec-work Needed) ==<br />
<br />
{|<br />
! Priority !! Spec !! Comments<br />
|-<br />
| LI || CSS Background and Borders L4 || <br />
|-<br />
| SI || CSS Image Values and Replaced Content Module LEVEL 4 || <br />
|-<br />
| NI || CSS Pseudo-Elements L4 || <br />
|-<br />
| LI || CSS Text L4 || <br />
|-<br />
| SI || Media Queries L4 || <br />
|-<br />
| VSI || Selectors L4 || <br />
|}<br />
<br />
== FXTF Working Drafts (Spec-work Needed) ==<br />
<br />
{|<br />
! Priority !! Spec !! Comments<br />
|-<br />
| ? || Compositing and Blending ||<br />
|-<br />
| ? || Filter Effects ||<br />
|-<br />
| ? || Masking ||<br />
|-<br />
| ? || Shaders ||<br />
|}</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Platform/Layout/CSS/CSSWG_Priorities_2012&diff=470158Platform/Layout/CSS/CSSWG Priorities 20122012-09-12T21:31:38Z<p>Fantasai: create table of priorities from CSSWG survey</p>
<hr />
<div>= CSSWG Priorities 2012 =<br />
<br />
== Key ==<br />
<br />
"very strong interest" (VSI), "strong interest" (SI), "low interest" (LI) or "not interested" (NI)<br />
<br />
== Candidate Recommendations (Testing Needed) ==<br />
<br />
{|<br />
! Priority !! Spec !! Comments<br />
|-<br />
| || CSS Backgrounds and Borders Module L3 || <br />
|-<br />
| || CSS Flexible Box Layout Module L1 || <br />
|-<br />
| || CSS Image Values and Replaced Content L3 || <br />
|-<br />
| || CSS Multi-column Layout Module || <br />
|-<br />
| || CSS Speech L1 || <br />
|-<br />
| || CSS Style Attribute L1 || <br />
|-<br />
| || CSS Values and Units Module L3 || <br />
|}<br />
<br />
== CSS3 Working Drafts (Spec-work Needed) ==<br />
<br />
{|<br />
! Priority !! Spec !! Comments<br />
|-<br />
| || CSS Animations L1 || <br />
|-<br />
| || CSS Box Model L3 || <br />
|-<br />
| || CSS Box Alignment Module L3 || <br />
|-<br />
| || CSS Color Correction || <br />
|-<br />
| || CSS Conditional Rules Module L3 || <br />
|-<br />
| || CSS Counter Styles L3 || <br />
|-<br />
| || CSS Device Adaptation || <br />
|-<br />
| || CSS Exclusions and Shapes || <br />
|-<br />
| || CSS Fonts L3 || <br />
|-<br />
| || CSS Fragmentation Module L3 || <br />
|-<br />
| || CSS GCPM || <br />
|-<br />
| || CSS Grid Layout || <br />
|-<br />
| || CSS Grid Template Layout || <br />
|-<br />
| || CSS Hierarchies || <br />
|-<br />
| || CSS Intrinsic & Extrinsic Sizing Module L3 || <br />
|-<br />
| || CSS Line Grid Module || <br />
|-<br />
| || CSS Line Layout L3 || <br />
|-<br />
| || CSS Lists and Counters Module L3 || <br />
|-<br />
| || CSS Mobile Text Size Adjustment Module || <br />
|-<br />
| || CSS Paged Media Module L3 || <br />
|-<br />
| || CSS Pagination Templates Module || <br />
|-<br />
| || CSS Positioned Layout Module L3 || <br />
|-<br />
| || CSS Overflow Module || <br />
|-<br />
| || CSS Regions || <br />
|-<br />
| || CSS Ruby ||<br />
|-<br />
| || CSS Syntax L3 || <br />
|-<br />
| || CSS Text Decoration Module L3 || <br />
|-<br />
| || CSS Text Module L3 || <br />
|-<br />
| || CSS Transforms || <br />
|-<br />
| || CSS Transitions || <br />
|-<br />
| || CSS UI || <br />
|-<br />
| || CSS Writing Modes L3 || <br />
|}<br />
<br />
== CSSOM Working Drafts (Spec-work Needed) ==<br />
<br />
{|<br />
! Priority !! Spec !! Comments<br />
|-<br />
| || CSS OM Values Module || <br />
|-<br />
| || CSS OM View Module || <br />
|-<br />
| || CSS OM || <br />
|}<br />
<br />
== CSS4 Working Drafts (Spec-work Needed) ==<br />
<br />
{|<br />
! Priority !! Spec !! Comments<br />
|-<br />
| || CSS Background and Borders L4 || <br />
|-<br />
| || CSS Image Values and Replaced Content Module LEVEL 4 || <br />
|-<br />
| || CSS Pseudo-Elements L4 || <br />
|-<br />
| || CSS Text L4 || <br />
|-<br />
| || Media Queries L4 || <br />
|-<br />
| || Selectors L4 || <br />
|}<br />
<br />
== FXTF Working Drafts (Spec-work Needed) ==<br />
<br />
{|<br />
! Priority !! Spec !! Comments<br />
|-<br />
| || Compositing and Blending ||<br />
|-<br />
| || Filter Effects ||<br />
|-<br />
| || Masking ||<br />
|-<br />
| || Shaders ||<br />
|}</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Platform/2012-Q3-Goals&diff=456191Platform/2012-Q3-Goals2012-07-30T20:55:53Z<p>Fantasai: /* Layout */ update specs subsection to include stuff embedded in code project list</p>
<hr />
<div>=== General Goals ===<br />
<br />
=== GFX ===<br />
<onlyinclude><br />
* {{ok|stop using Java screenshotting in Fennec for Android}}<br />
** we agree that we want to do this, but we have concerns that the pieces will be there, but we'll still be unable to turn off java screenshotting because of performance problems.<br />
** alternative: "implement multi-resolution tiles"<br />
* {{ok|complete asynchronous panning and zooming with OMTC for B2G/gonk}}<br />
* {{ok|Ship OMTC on B2G/gonk for basecamp}}<br />
* {{ok|Be able to use Skia for canvas drawing on non-accelerated Windows computers}} <br />
** gw280 to gather skia software-only performance numbers by Tuesday 3 July to help make a decision<br />
** carryover - do we care at this point, given the below item?<br />
* {{ok|Be able to use Skia for content drawing on Android}}<br />
* {{ok|Remove the non-Azure canvas implementation}}<br />
** Use the Cairo Azure backend everywhere there isn't a more specific backend<br />
* {{ok|OMTC cross-platform refactor}}<br />
** Risky!<br />
** Not back-outable. No OMTC or "New OMTC" only.<br />
** Needed so we can enable OMTC everywhere.<br />
* {{ok|Have a clean, dependable, extensible, all-platform, free-of-adverse-cache-effects driver blacklisting solution.}}<br />
* Other important Q3 work<br />
** WebGL work. bjacob to fill in what this means.<br />
** Enable Azure for content everywhere<br />
** Snappy work<br />
** Other B2G work as required<br />
** Moving other pieces of work off the main thread<br />
** BugKill - ???<br />
** Increase number of regular contributors<br />
</onlyinclude><br />
<br />
=== Layout ===<br />
<br />
<onlyinclude><br />
* {{ok|Readability 2.0}}<br />
* {{ok|Complete Graphite Fonts Project}} ({{bug|631479}})<br />
* {{ok|Invalidation via DisplayList Analysis ({{bug|539356}})}}<br />
* {{ok|CSS Flexbox feature/spec}} ({{bug|666041}})<br />
* {{ok|Add image visibility API ({{bug|689623}})}}<br />
* {{risk|Continue View class removal ({{bug|337801}})}}<br />
* {{ok|CSS}} [[Platform/Features/Vertical_text|Vertical Text]] ({{bug|145503}})<br />
* {{ok|CSS Pagination}} ({{bug|775628}})<br />
* {{ok|CSS Variables}} ({{bug|773296}})<br />
* {{ok|Implement the auto value for the HTML dir attribute ({{bug|548206}})}}<br />
* {{ok|CSS 2.1 Test Suite v.2}}<br />
* {{ok|CSS Spec, Unprefixing & Testing}} ({{bug|775235}})<br />
* {{ok|Conditional Rules feature & spec}} ({{bug|649740}})<br />
* {{ok|Scoped Style Sheets}} ({{bug|508725}})<br />
* {{ok|SVG Text}} ({{bug|655877}})<br />
* {{ok|Off Main Thread Animations}} ({{bug|755084}}, {{bug|706179}})<br />
* {{risk|Layout Azure Conversion}} ({{bug|776197}} - needs staffing)<br />
* {{prev|Support for Complex Scripts on Mobile}}<br />
** Example bugs: {{bug|619521}}, {{bug|619524}}, {{bug|676068}}, {{bug|631159}}<br />
* Specs:<br />
** Web Animations (FPWD)<br />
** CSS Flexbox (CR)<br />
** CSS Cascade L3 (spec scoped style)<br />
** CSS Conditional L3 (CR)<br />
** CSS Text L3 (LCWD)<br />
** Selectors L4<br />
</onlyinclude><br />
<br />
=== Media ===<br />
* {{ok|WebRTC (tracking the W3C and IETF webrtc/rtcweb specs) landed for desktop in mozilla-central. (This includes both PeerConnection and full getUserMedia, but not UI.)}}<br />
* {{ok|Platform decoders running on the Otoro device will playback videos at a similar performance metric to the equivalent android player}}<br />
* {{ok|For a specific list of Android phones (the list will be the "first phase" of Android phones), platform decoders running in Firefox will playback videos at a similar performance metric to the videos playing back in the default browser on the same phone}}<br />
* {{ok|Publish (to one or more of our newsgroups) a plan for supporting the Web Audio API. (We're still hoping to make improvements to the spec.)}}<br />
<br />
Mission Note: The media team will support B2G's efforts to ship B2G version 1 above any goals for this quarter.<br />
<br />
=== DOM ===<br />
* {{ok|Stop leaks by adding purple buffer support for cycle collected non-nsISupports objects.}}<br />
* {{ok|Speed up cycle collection by representing a DOM tree as a single node in the cycle collector graph.}}<br />
* {{ok|New DOM bindings for a HTML Element.}}<br />
<br />
=== WebAPI ===<br />
* {{ok|Implement cookie-jars for cookies, IndexedDB, localStorage, permission manager and appcache ({{bug|756644}})}}<br />
* {{ok|Implement app:// protocol (part of implementing trusted apps, {{bug|756729}})}}<br />
* {{ok|Finalize multiprocess blob support for IndexedDB, DeviceStorage and Message Manager ({{bug|759427}})}}<br />
* {{ok|Implement unified offline storage quota system, putting IndexedDB and localStorage under this quota system ({{bug|767944}})}}<br />
* {{ok|Zip file contents support using blobs ({{bug|772434}})}}<br />
* {{ok|DeviceStorage improvements (expose available (free) size for each device storage, storage[x].removable ({{bug|765498}})}}<br />
* {{ok|FileHandle [[WebAPI/FileHandleAPI#ToDo | improvements]]}}<br />
* {{ok|DeviceStorage onchange notifications ({{bug|763976}})}}<br />
* {{ok|DeviceStorage editable features ({{bug|752724}})}}<br />
* {{ok|String encoding/decoding API ({{bug|764234}})}}<br />
<br />
=== JS ===<br />
<br />
*{{ok|Land IonMonkey}}<br />
*{{ok|Incremental sweeping: get GC pauses consistently below 20ms}}<br />
*{{ok|Generational GC: get automated safety checks running and green}}<br />
*{{ok|Finish properties/elements split}}<br />
*{{ok|ES6: direct proxies}} [{{bug|703537}}]<br />
*{{ok|ES6: modules}} [{{bug|568953}}]<br />
<br />
=== Accessibility ===<br />
* {{ok| Preliminary AccessFu support in B2G.}}<br />
* {{ok| TTS Web API & implementation.}}<br />
* {{ok| Performance: add two additional measures of a11y's effect on perf. Additionally, show measurable perf increase of at least 10% on two measures.}}<br />
<br />
=== Perf ===<br />
* {{prev|{{nbug|736144}}: Async local storage via blocking pageload}}<br />
* {{prev|{{nbug|563742}}: provide js file api (in workers) for all supported platforms.}}<br />
* {{prev|{{nbug|662397}}: Reorder xul.dll on windows to speed up startup}}<br />
* {{prev|{{nbug|662444}}: call exit(0) on shutdown}}<br />
* {{prev|{{nbug|661881}}: Bundle about-telemetry extension to ship with Firefox}}<br />
* {{ok|{{nbug|769241}}: Make libunwind work on ARM}}<br />
* {{prev|Prevent, to a reasonable extent, background tabs from starving the main thread}}<br />
* {{ok|{{nbug|770317}}: Track disk + network by thread on testing infrastructure}}<br />
<br />
=== Networking ===<br />
<br />
* {{ok|Remove all synchronous disk cache APIs, or at least disable their use on the main thread, on mozilla-central.}}<br />
** Nick Hurley and Michal Novotny will lead this effort.<br />
* {{ok|{{nbug|766973}}: Don't allow synchronous DNS resolution from the main thread.}}<br />
** Josh Aas will lead this effort.<br />
* {{ok|{{nbug|105843}}: Land code to not necessarily delete the cache after unclean shut-down on mozilla-central.}}<br />
** Nick Hurley and Michal Novotny will lead this effort.<br />
* {{ok|Have Stone Ridge reliably reporting basic performance results to graph server for all three top-tier platforms.}}<br />
** Nick Hurley will lead this effort.<br />
* {{ok|{{nbug|768705}}, {{nbug|704447}}, {{nbug|766817}}: Fix some remaining significant WebSockets bugs.}}<br />
** Jason Duell will lead this effort.<br />
* {{ok|{{nbug|702122}}: Land a DASH for WebM implementation in mozilla-central.}}<br />
** Steve Workman will lead this effort.<br />
* {{ok|{{nbug|737470}}: Ship SPDY v3 on by default.}}<br />
** Patrick McManus will lead this effort.<br />
* {{ok|Resolve all networking security bugs that received a designation of sg:moderate or higher more than six weeks ago. This is a permanent goal for the group.}}<br />
** Brian Smith will lead this effort.<br />
<br />
=== Plugins ===<br />
<br />
=== Mobile ===<br />
<br />
=== B2G ===<br />
<br />
=== Research ===</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Platform/Layout/CSS&diff=415394Platform/Layout/CSS2012-04-02T23:41:17Z<p>Fantasai: </p>
<hr />
<div>= CSS Implementation Tracking =<br />
<br />
This page links to the tracking bugs for various CSS specs. It mirrors the CSSWG's [http://www.w3.org/Style/CSS/current-work current-work] page<br />
<br />
== Stable ==<br />
<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=css2.1-tests CSS2.1]<br />
* CSS Color Level 3<br />
* CSS Namespaces<br />
* Media Queries Level 3<br />
* Selectors Level 3 <br />
<br />
== Testing ==<br />
<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=css3-background CSS Backgrounds and Borders Level 3]<br />
* CSS Multi-column Layout<br />
* CSS Image Values and Replaced Content Level 3<br />
<br />
== Refining ==<br />
<br />
* CSS Animations<br />
* CSS Transforms<br />
* CSS Transitions<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=css3-values CSS Values and Units Level 3]<br />
<br />
== Revising ==<br />
<br />
* CSS Flexbox<br />
* CSS Fonts Level 3<br />
* CSS Paged Media Level 3<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=css3-text CSS Text Level 3]<br />
* CSS Writing Modes Level 3<br />
<br />
== Exploring ==<br />
<br />
* CSS Conditional Rules Level 3<br />
* CSS Fragmentation Level 3<br />
* CSS Grid Layout Level 3<br />
* CSS Line Layout Level 3<br />
* CSS Ruby</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Platform/Layout/CSS&diff=415378Platform/Layout/CSS2012-04-02T23:32:50Z<p>Fantasai: Created page with "= CSS Implementation Tracking = This page links to the tracking bugs for various CSS specs. It mirrors the CSSWG's [http://www.w3.org/Style/CSS/current-work current-work] page ..."</p>
<hr />
<div>= CSS Implementation Tracking =<br />
<br />
This page links to the tracking bugs for various CSS specs. It mirrors the CSSWG's [http://www.w3.org/Style/CSS/current-work current-work] page<br />
<br />
== Stable ==<br />
<br />
* CSS2.1<br />
* CSS Color Level 3<br />
* CSS Namespaces<br />
* Media Queries Level 3<br />
* Selectors Level 3 <br />
<br />
== Testing ==<br />
<br />
* CSS Backgrounds and Borders Level 3<br />
* CSS Multi-column Layout<br />
* CSS Image Values and Replaced Content Level 3<br />
<br />
== Refining ==<br />
<br />
* CSS Animations<br />
* CSS Transforms<br />
* CSS Transitions<br />
* CSS Values and Units Level 3<br />
<br />
== Revising ==<br />
<br />
* CSS Flexbox<br />
* CSS Fonts Level 3<br />
* CSS Paged Media Level 3<br />
* CSS Text Level 3<br />
* CSS Writing Modes Level 3<br />
<br />
== Exploring ==<br />
<br />
* CSS Conditional Rules Level 3<br />
* CSS Fragmentation Level 3<br />
* CSS Grid Layout Level 3<br />
* CSS Line Layout Level 3<br />
* CSS Ruby</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Platform/Layout&diff=413376Platform/Layout2012-03-28T21:47:06Z<p>Fantasai: /* Feature Planning */</p>
<hr />
<div>The Layout Team is primarily responsible for the [http://en.wikipedia.org/wiki/Gecko_%28layout_engine%29 Gecko Layout Engine]. A programmer's primer is posted here:<br />
https://wiki.mozilla.org/Gecko:Overview<br />
<br />
== Quarterly Planning ==<br />
<br />
See the [[Platform/Planning | Platform Planning page]] for info on our meetings that occur 2-3 times a year to plan features.<br />
<br />
== Feature Planning ==<br />
<br />
* Goals of new features:<br />
** UI layout<br />
** Magazines/ebook layout<br />
** Language support<br />
<br />
* [[Platform/Layout/CSS|CSS]]<br />
** Flexbox<br />
*** horizontal/vertical<br />
*** single/multi-line<br />
** Grid Layout<br />
** Pagination<br />
*** Pagination controls<br />
*** Better pagination (tables, abspos)<br />
** CSS Conditional<br />
*** @supports<br />
** CSS Images <br />
*** gradients (syntax changes, animation)<br />
* Need better proposals for<br />
** CSS Regions<br />
** CSS Exclusions<br />
* Other<br />
** CSS Paginated Overflow<br />
** Scrolling APIs<br />
** Ruby<br />
** Seamless IFRAME / media queries<br />
<br />
* [[Platform/Layout/Text|Text]]<br />
** Mobile Readability<br />
** Writing Modes (vertical text, etc.)<br />
** Graphite<br />
** Ruby<br />
* [[Platform/Layout/Responsiveness|Responsiveness/Performance]]<br />
** View removal<br />
** Display-List based invalidation<br />
** SVG Display-List conversion<br />
** Font cache performance improvements<br />
<br />
== Development Planning ==<br />
<br />
* [[Platform/Layout/BugKill|BugKill - make our bug lists containable in one person's head]]<br />
<br />
== Other Information ==<br />
<br />
* [https://intranet.mozilla.org/Layout_DOM_Work_Week_-_March_2012 DOM/Layout Work Week 2012]<br />
* [https://intranet.mozilla.org/GraphicsLayoutWorkWeek-November2011 GFx/Layout Work Week 2011]</div>Fantasaihttps://wiki.mozilla.org/index.php?title=2012/SXSW&diff=4041942012/SXSW2012-03-05T22:16:58Z<p>Fantasai: /* Mozillians at SXSW 2012 */</p>
<hr />
<div>= SXSW 2012 =<br />
== Summary ==<br />
Mozilla participation in SXSW 2012.<br />
<br />
<div class="h-event vevent"><br />
* <span class="dt-start dtstart">2012-03-09</span>...<span class="dt-end dtend">2012-03-18</span> <span class="p-summary summary">[http://lanyrd.com/2012/sxsw-interactive/ SXSW]</span> at <span class="p-location location h-adr adr"><span class="p-locality locality">Austin</span> <abbr class="p-region region" title="Texas">TX</abbr></span>. <span class="u-url url">https://wiki.mozilla.org/2012/SXSW</span>.<br />
<br />
Notes:<br />
* SXSW is apparently going to be even bigger this year. Venues will be quite spread out.<br />
* '''Daylight savings time starts on Sunday.''' Move your clocks forward. This means that Sunday morning talks are an hour earlier than you'd expect them to be.<br />
* [http://forecast.weather.gov/MapClick.php?smap=1&lat=30.267&lon=-97.743&unit=0&mp=1 Weather forecast]<br />
<br />
== Mozillians at SXSW 2012 ==<br />
{|<br />
|-<br />
! Name<br />
! Arriving<br />
! Leaving<br />
! Notes<br />
|-class="attendee vcard"<br />
| <span class="fn p-attendee h-card">[[User:Dbaron|David Baron]]</span><br />
| Thu 8<br />
| Wed 14<br />
| <span class="role">speaker</span> on [http://schedule.sxsw.com/2012/events/event_IAP12909 Fast CSS: How Browsers Lay out Web Pages] (Sunday 11am-noon '''daylight savings time''')<br />
|-class="attendee vcard"<br />
| <span class="fn p-attendee h-card">[[User:Tantek|Tantek Çelik]]</span><br />
|<br />
|<br />
| Interactive Advisory Board member, and <span class="role">speaker</span> on [http://schedule.sxsw.com/2012/events/event_IAP12752 Rise of The Indie Web] (Saturday 3:30pm-4:30pm)<br />
|-class="attendee vcard"<br />
| <span class="fn p-attendee h-card">Brendan Eich</span><br />
| <br />
| <br />
| <span class="role">speaker</span> on [http://schedule.sxsw.com/2012/events/event_IAP12185 Browser Wars V: The Angry Birds Era] (Saturday, 5:00pm-6:00pm)<br />
|-class="attendee vcard"<br />
| <span class="fn p-attendee h-card">Elika Etemad</span><br />
| Thu 8<br />
| Wed 14<br />
| <span class="role">speaker</span> on [http://schedule.sxsw.com/2012/events/event_IAP10893 CSS.next: Current Experiments, CSS4 and the Future] (Sunday 12:30pm-1:30pm '''daylight savings time''')<br />
|-class="attendee vcard"<br />
| <span class="fn p-attendee h-card">Brett Gaylor</span><br />
|<br />
|<br />
| <span class="role">speaker</span> on [http://schedule.sxsw.com/2012/events/event_FP13743 Does HTML5 Offer a Montage Moment for Web Cinema?] (Sunday, 12:30pm-1:30pm '''daylight savings time''')<br />
|-class="attendee vcard"<br />
| <span class="fn p-attendee h-card">Gary Kovacs</span><br />
|<br />
|<br />
| <span class="role">speaker</span> on [http://schedule.sxsw.com/2012/events/event_IAP992460 SOPA/PIPA: Why the Open Internet Needs Us] (Saturday 11:00am-noon)<br />
|-class="attendee vcard"<br />
| <span class="fn p-attendee h-card">Dan Sinker</span> <br />
|<br />
|<br />
| <span class="role">speaker</span> on [http://schedule.sxsw.com/2012/events/event_IAP11939 Open Web, Open News: Reporters & Developers Remix] (Sunday 3:30pm-4:30pm)<br />
|-class="attendee vcard"<br />
| <span class="fn p-attendee h-card">Boris Zbarsky</span><br />
|<br />
|<br />
| <span class="role">speaker</span> on [http://schedule.sxsw.com/2012/events/event_IAP10893 CSS.next: Current Experiments, CSS4 and the Future] (Sunday 12:30pm-1:30pm '''daylight savings time''')<br />
|}<br />
<br />
== Events with Mozillians ==<br />
<br />
{|<br />
|-<br />
! Day<br />
! Time<br />
! Event<br />
! Mozillians<br />
|-<br />
| Saturday<br />
| 11:00am-noon<br />
| [http://schedule.sxsw.com/2012/events/event_IAP992460 SOPA/PIPA: Why the Open Internet Needs Us] <br />
| Gary Kovacs<br />
|-<br />
| Saturday<br />
| 3:30pm-4:30pm<br />
| [http://schedule.sxsw.com/2012/events/event_IAP12752 Rise of The Indie Web]<br />
| Tantek Çelik<br />
|-<br />
| Saturday<br />
| 5:00pm-6:00pm<br />
| [http://schedule.sxsw.com/2012/events/event_IAP12185 Browser Wars V: The Angry Birds Era]<br />
| Brendan Eich<br />
|-<br />
| Sunday<br />
| 11:00am-noon C'''D'''T<br />
| [http://schedule.sxsw.com/2012/events/event_IAP12909 Fast CSS: How Browsers Lay out Web Pages]<br />
| David Baron<br />
|-<br />
| Sunday<br />
| 12:30pm - 1:30pm C'''D'''T<br />
| [http://schedule.sxsw.com/2012/events/event_IAP10893 CSS.next: Current Experiments, CSS4 and the Future]<br />
| Elika Etemad, Boris Zbarsky<br />
|-<br />
| Sunday<br />
| 12:30pm - 1:30pm C'''D'''T<br />
| [http://schedule.sxsw.com/2012/events/event_FP13743 Does HTML5 Offer a Montage Moment for Web Cinema?]<br />
| Brett Gaylor<br />
|-<br />
| Sunday<br />
| 3:30pm-4:30pm C'''D'''T<br />
| [http://schedule.sxsw.com/2012/events/event_IAP11939 Open Web, Open News: Reporters & Developers Remix]<br />
| Dan Sinker<br />
|}<br />
<br />
== Previous Years ==<br />
* [[Event:SXSW_Interactive_2011|SXSW 2011]]<br />
* [[Event:SXSW_Interactive_2010|SXSW 2010]]<br />
<br />
== See Also ==<br />
* [[Events]]<br />
* [https://developer.mozilla.org/en-US/events Where is Mozilla?]</div>Fantasaihttps://wiki.mozilla.org/index.php?title=2012/SXSW&diff=4041922012/SXSW2012-03-05T22:16:18Z<p>Fantasai: /* Mozillians at SXSW 2012 */</p>
<hr />
<div>= SXSW 2012 =<br />
== Summary ==<br />
Mozilla participation in SXSW 2012.<br />
<br />
<div class="h-event vevent"><br />
* <span class="dt-start dtstart">2012-03-09</span>...<span class="dt-end dtend">2012-03-18</span> <span class="p-summary summary">[http://lanyrd.com/2012/sxsw-interactive/ SXSW]</span> at <span class="p-location location h-adr adr"><span class="p-locality locality">Austin</span> <abbr class="p-region region" title="Texas">TX</abbr></span>. <span class="u-url url">https://wiki.mozilla.org/2012/SXSW</span>.<br />
<br />
Notes:<br />
* SXSW is apparently going to be even bigger this year. Venues will be quite spread out.<br />
* '''Daylight savings time starts on Sunday.''' Move your clocks forward. This means that Sunday morning talks are an hour earlier than you'd expect them to be.<br />
* [http://forecast.weather.gov/MapClick.php?smap=1&lat=30.267&lon=-97.743&unit=0&mp=1 Weather forecast]<br />
<br />
== Mozillians at SXSW 2012 ==<br />
{|<br />
|-<br />
! Name<br />
! Arriving<br />
! Leaving<br />
! Notes<br />
|-class="attendee vcard"<br />
| <span class="fn p-attendee h-card">[[User:Dbaron|David Baron]]</span><br />
| Thu 8<br />
| Wed 14<br />
| <span class="role">speaker</span> on [http://schedule.sxsw.com/2012/events/event_IAP12909 Fast CSS: How Browsers Lay out Web Pages] (Sunday 11am-noon '''daylight savings time''')<br />
|-class="attendee vcard"<br />
| <span class="fn p-attendee h-card">[[User:Tantek|Tantek Çelik]]</span><br />
|<br />
|<br />
| Interactive Advisory Board member, and <span class="role">speaker</span> on [http://schedule.sxsw.com/2012/events/event_IAP12752 Rise of The Indie Web] (Saturday 3:30pm-4:30pm)<br />
|-class="attendee vcard"<br />
| <span class="fn p-attendee h-card">Brendan Eich</span><br />
| Thu 8<br />
| Wed 14<br />
| <span class="role">speaker</span> on [http://schedule.sxsw.com/2012/events/event_IAP12185 Browser Wars V: The Angry Birds Era] (Saturday, 5:00pm-6:00pm)<br />
|-class="attendee vcard"<br />
| <span class="fn p-attendee h-card">Elika Etemad</span><br />
|<br />
|<br />
| <span class="role">speaker</span> on [http://schedule.sxsw.com/2012/events/event_IAP10893 CSS.next: Current Experiments, CSS4 and the Future] (Sunday 12:30pm-1:30pm '''daylight savings time''')<br />
|-class="attendee vcard"<br />
| <span class="fn p-attendee h-card">Brett Gaylor</span><br />
|<br />
|<br />
| <span class="role">speaker</span> on [http://schedule.sxsw.com/2012/events/event_FP13743 Does HTML5 Offer a Montage Moment for Web Cinema?] (Sunday, 12:30pm-1:30pm '''daylight savings time''')<br />
|-class="attendee vcard"<br />
| <span class="fn p-attendee h-card">Gary Kovacs</span><br />
|<br />
|<br />
| <span class="role">speaker</span> on [http://schedule.sxsw.com/2012/events/event_IAP992460 SOPA/PIPA: Why the Open Internet Needs Us] (Saturday 11:00am-noon)<br />
|-class="attendee vcard"<br />
| <span class="fn p-attendee h-card">Dan Sinker</span> <br />
|<br />
|<br />
| <span class="role">speaker</span> on [http://schedule.sxsw.com/2012/events/event_IAP11939 Open Web, Open News: Reporters & Developers Remix] (Sunday 3:30pm-4:30pm)<br />
|-class="attendee vcard"<br />
| <span class="fn p-attendee h-card">Boris Zbarsky</span><br />
|<br />
|<br />
| <span class="role">speaker</span> on [http://schedule.sxsw.com/2012/events/event_IAP10893 CSS.next: Current Experiments, CSS4 and the Future] (Sunday 12:30pm-1:30pm '''daylight savings time''')<br />
|}<br />
<br />
== Events with Mozillians ==<br />
<br />
{|<br />
|-<br />
! Day<br />
! Time<br />
! Event<br />
! Mozillians<br />
|-<br />
| Saturday<br />
| 11:00am-noon<br />
| [http://schedule.sxsw.com/2012/events/event_IAP992460 SOPA/PIPA: Why the Open Internet Needs Us] <br />
| Gary Kovacs<br />
|-<br />
| Saturday<br />
| 3:30pm-4:30pm<br />
| [http://schedule.sxsw.com/2012/events/event_IAP12752 Rise of The Indie Web]<br />
| Tantek Çelik<br />
|-<br />
| Saturday<br />
| 5:00pm-6:00pm<br />
| [http://schedule.sxsw.com/2012/events/event_IAP12185 Browser Wars V: The Angry Birds Era]<br />
| Brendan Eich<br />
|-<br />
| Sunday<br />
| 11:00am-noon C'''D'''T<br />
| [http://schedule.sxsw.com/2012/events/event_IAP12909 Fast CSS: How Browsers Lay out Web Pages]<br />
| David Baron<br />
|-<br />
| Sunday<br />
| 12:30pm - 1:30pm C'''D'''T<br />
| [http://schedule.sxsw.com/2012/events/event_IAP10893 CSS.next: Current Experiments, CSS4 and the Future]<br />
| Elika Etemad, Boris Zbarsky<br />
|-<br />
| Sunday<br />
| 12:30pm - 1:30pm C'''D'''T<br />
| [http://schedule.sxsw.com/2012/events/event_FP13743 Does HTML5 Offer a Montage Moment for Web Cinema?]<br />
| Brett Gaylor<br />
|-<br />
| Sunday<br />
| 3:30pm-4:30pm C'''D'''T<br />
| [http://schedule.sxsw.com/2012/events/event_IAP11939 Open Web, Open News: Reporters & Developers Remix]<br />
| Dan Sinker<br />
|}<br />
<br />
== Previous Years ==<br />
* [[Event:SXSW_Interactive_2011|SXSW 2011]]<br />
* [[Event:SXSW_Interactive_2010|SXSW 2010]]<br />
<br />
== See Also ==<br />
* [[Events]]<br />
* [https://developer.mozilla.org/en-US/events Where is Mozilla?]</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Platform/Layout/CSS_Compatibility&diff=394721Platform/Layout/CSS Compatibility2012-02-07T08:37:59Z<p>Fantasai: /* questions and methodology */</p>
<hr />
<div>= CSS vendor-prefix compatibility =<br />
<br />
== problem statement ==<br />
Sites that have WebKit-specific content and back-up content for everyone else.<br />
<br />
-webkit- properties are used so much on mobile content in particular that non-WebKit browsers face a Prisoner's Dilemma problem, analogous to past quirks battles (e.g. 2003-4 era innerHTML and undetected document.all).<br />
<br />
data: https://bugzilla.mozilla.org/show_bug.cgi?id=708406<br />
<br />
=== more problem details ===<br />
Blog posts:<br />
* http://hsivonen.iki.fi/vendor-prefixes/<br />
* http://blogs.msdn.com/b/iemobile/archive/2010/05/10/javascript-and-css-changes-in-ie-mobile-for-windows-phone-7.aspx in particular: <blockquote><p>"We've also added support for the -webkit-text-size-adjust CSS selector. This selector allows you to control how text on the Web page is scaled to increase readability for the user (you can also use -ms-text-size-adjust, IE Mobile recognizes both).</p><p> ... [one day later] ... </p><p><b>"[Update 05/11/2010: based on community feedback, we will only be implementing the -ms- prefix, not the -webkit- one.]"</b></p><br />
<br />
== goals ==<br />
The underlying open web goal: <br />
<br />
* Open up the webkit-specific part of the web to other vendors in the same way that we had to be practical about what IE-proprietary or IE-only technologies to support.<br />
<br />
== straw proposal ==<br />
* Consider implementing some -webkit- prefixed properties.<br />
<br />
== straw proposal downsides ==<br />
* Unfortunately for the open web, implementing a -webkit- prefixed property (outside of WebKit) will nearly legitimize (make people assume they'll work forever) the use of -webkit- prefixed properties.<br />
* ...<br />
<br />
== possible downside mitigation ==<br />
* In the short term we can at least remove pain for web authors and users.<br />
* In the long term we can ensure the unprefixed properties (in CR drafts) work and encourage authors to switch to them.<br />
* ...<br />
<br />
== questions and methodology ==<br />
* What are the thresholds (even approximate) for supporting an other-vendor prefixed property vs. not?<br />
* How should we consider occurrence counts of -webkit- properties? <br />
** Weighted by PageRank or equivalent?<br />
* Consider usability of page with/without the feature, not just how often it is used. E.g. tap-highlight-color does not affect the user's ability to use a website the same way text-size-adjust does.<br />
<br />
== parsing other vendor prefixes approaches ==<br />
* parse other vendor prefixed properties only in conjunction with parsing the equivalent unprefixed properties<br />
* only do it for environments where critically necessary, i.e. mobile not desktop, to encourage use of standard equivalents.<br />
<br />
== unprefixing principles ==<br />
* unprefixing things early (before CR) should be an exceptional case<br />
** what is the methodology for "exceptional" unprefixing?<br />
* unprefixing things must be evaluated carefully on case-by-case basis.<br />
* unprefixing is not something to do routinely just to "go faster" by a few months.<br />
** put the energy first into contributing and passing test suites instead.<br />
* ...<br />
<br />
== Data on vendor-specific prefixes ==<br />
Here's a summary of the data collection and analysis that has been conducted regarding the use of various CSS vendor-specific prefixes.<br />
<br />
The current datasets, collected by John Jensen, are:<br />
<br />
=== Initial CSS properties dataset ===<br />
* Completed in November 2011<br />
* Summary of 88,000 CSS files from top 30,000 sites on the web, collected using Desktop FF 8.0 User-Agent<br />
* Tables and summary reports in https://bugzilla.mozilla.org/show_bug.cgi?id=708406<br />
* Written report and summary tables are attached to the ticket. <br />
* Summary file, in CSV format, is 620MB compressed, 7.2GB uncompressed, available at http://people.mozilla.com/~jjensen/css.csv.gz<br />
<br />
==== Q and A ====<br />
* how many sites in your mobile Webkit browser crawl use at least one of 'transition', 'transition-timing-function', 'transition-duration', 'transition-property', 'transition-delay' (ignoring prefixes)?<br />
<br />
1245 / 30087 = 4.13%<br />
<br />
* how many use them only with -webkit prefixes (no -moz or unprefixed versions of the properties)?<br />
<br />
336 / 30087 = 1.12%<br />
<br />
* how many use them only with -webkit prefixes and unprefixed (no -moz versions of the properties)?<br />
365 / 30087 = 1.21%<br />
<br />
* For each CSS prefix for which there are both -moz- and -webkit- prefixes, what percentage of domains host CSS that uses only the -webkit- version and not the -moz- or unprefixed version?<br />
<br />
{|<br />
| text-size-adjust||510||1.70%<br />
|-<br />
| box-shadow||428||1.42%<br />
|-<br />
| border-radius||412||1.37%<br />
|-<br />
|appearance||379||1.26%<br />
|-<br />
|font-smoothing||285||0.95%<br />
|-<br />
|tap-highlight-color||250||0.83%<br />
|-<br />
|transform||75||0.25%<br />
|-<br />
|border-top-left-radius||72||0.24%<br />
|-<br />
|border-top-right-radius||72||0.24%<br />
|-<br />
|transition-duration||61||0.20%<br />
|-<br />
|animation-duration||56||0.19%<br />
|-<br />
|animation-name||56||0.19%<br />
|-<br />
|border-bottom-left-radius||55||0.18%<br />
|-<br />
|border-bottom-right-radius||55||0.18%<br />
|-<br />
|transition-property||49||0.16%<br />
|-<br />
|animation-iteration-count||45||0.15%<br />
|-<br />
|padding-start||45||0.15%<br />
|-<br />
|background-size||43||0.14%<br />
|-<br />
|animation-timing-function||42||0.14%<br />
|-<br />
|box-sizing||42||0.14%<br />
|}<br />
<br />
=== Larger, as-yet-unprocessed datasets ===<br />
* Raw data downloading completed in mid-January 2012, using these UAs:<br />
# latest Android Native Browser from ICS<br />
# latest Mobile Safari UA<br />
* Includes all HTML, Javascript, CSS files in compressed format<br />
* Roughly 1.1m files downloaded for each UA<br />
* CSS file parsing is underway to produce more data</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Platform/Layout/CSS_Compatibility&diff=394720Platform/Layout/CSS Compatibility2012-02-07T08:36:45Z<p>Fantasai: /* parsing other vendor prefixes approaches */</p>
<hr />
<div>= CSS vendor-prefix compatibility =<br />
<br />
== problem statement ==<br />
Sites that have WebKit-specific content and back-up content for everyone else.<br />
<br />
-webkit- properties are used so much on mobile content in particular that non-WebKit browsers face a Prisoner's Dilemma problem, analogous to past quirks battles (e.g. 2003-4 era innerHTML and undetected document.all).<br />
<br />
data: https://bugzilla.mozilla.org/show_bug.cgi?id=708406<br />
<br />
=== more problem details ===<br />
Blog posts:<br />
* http://hsivonen.iki.fi/vendor-prefixes/<br />
* http://blogs.msdn.com/b/iemobile/archive/2010/05/10/javascript-and-css-changes-in-ie-mobile-for-windows-phone-7.aspx in particular: <blockquote><p>"We've also added support for the -webkit-text-size-adjust CSS selector. This selector allows you to control how text on the Web page is scaled to increase readability for the user (you can also use -ms-text-size-adjust, IE Mobile recognizes both).</p><p> ... [one day later] ... </p><p><b>"[Update 05/11/2010: based on community feedback, we will only be implementing the -ms- prefix, not the -webkit- one.]"</b></p><br />
<br />
== goals ==<br />
The underlying open web goal: <br />
<br />
* Open up the webkit-specific part of the web to other vendors in the same way that we had to be practical about what IE-proprietary or IE-only technologies to support.<br />
<br />
== straw proposal ==<br />
* Consider implementing some -webkit- prefixed properties.<br />
<br />
== straw proposal downsides ==<br />
* Unfortunately for the open web, implementing a -webkit- prefixed property (outside of WebKit) will nearly legitimize (make people assume they'll work forever) the use of -webkit- prefixed properties.<br />
* ...<br />
<br />
== possible downside mitigation ==<br />
* In the short term we can at least remove pain for web authors and users.<br />
* In the long term we can ensure the unprefixed properties (in CR drafts) work and encourage authors to switch to them.<br />
* ...<br />
<br />
== questions and methodology ==<br />
* What are the thresholds (even approximate) for supporting an other-vendor prefixed property vs. not?<br />
* How should we consider occurrence counts of -webkit- properties? <br />
** Weighted by PageRank or equivalent?<br />
* ...<br />
<br />
== parsing other vendor prefixes approaches ==<br />
* parse other vendor prefixed properties only in conjunction with parsing the equivalent unprefixed properties<br />
* only do it for environments where critically necessary, i.e. mobile not desktop, to encourage use of standard equivalents.<br />
<br />
== unprefixing principles ==<br />
* unprefixing things early (before CR) should be an exceptional case<br />
** what is the methodology for "exceptional" unprefixing?<br />
* unprefixing things must be evaluated carefully on case-by-case basis.<br />
* unprefixing is not something to do routinely just to "go faster" by a few months.<br />
** put the energy first into contributing and passing test suites instead.<br />
* ...<br />
<br />
== Data on vendor-specific prefixes ==<br />
Here's a summary of the data collection and analysis that has been conducted regarding the use of various CSS vendor-specific prefixes.<br />
<br />
The current datasets, collected by John Jensen, are:<br />
<br />
=== Initial CSS properties dataset ===<br />
* Completed in November 2011<br />
* Summary of 88,000 CSS files from top 30,000 sites on the web, collected using Desktop FF 8.0 User-Agent<br />
* Tables and summary reports in https://bugzilla.mozilla.org/show_bug.cgi?id=708406<br />
* Written report and summary tables are attached to the ticket. <br />
* Summary file, in CSV format, is 620MB compressed, 7.2GB uncompressed, available at http://people.mozilla.com/~jjensen/css.csv.gz<br />
<br />
==== Q and A ====<br />
* how many sites in your mobile Webkit browser crawl use at least one of 'transition', 'transition-timing-function', 'transition-duration', 'transition-property', 'transition-delay' (ignoring prefixes)?<br />
<br />
1245 / 30087 = 4.13%<br />
<br />
* how many use them only with -webkit prefixes (no -moz or unprefixed versions of the properties)?<br />
<br />
336 / 30087 = 1.12%<br />
<br />
* how many use them only with -webkit prefixes and unprefixed (no -moz versions of the properties)?<br />
365 / 30087 = 1.21%<br />
<br />
* For each CSS prefix for which there are both -moz- and -webkit- prefixes, what percentage of domains host CSS that uses only the -webkit- version and not the -moz- or unprefixed version?<br />
<br />
{|<br />
| text-size-adjust||510||1.70%<br />
|-<br />
| box-shadow||428||1.42%<br />
|-<br />
| border-radius||412||1.37%<br />
|-<br />
|appearance||379||1.26%<br />
|-<br />
|font-smoothing||285||0.95%<br />
|-<br />
|tap-highlight-color||250||0.83%<br />
|-<br />
|transform||75||0.25%<br />
|-<br />
|border-top-left-radius||72||0.24%<br />
|-<br />
|border-top-right-radius||72||0.24%<br />
|-<br />
|transition-duration||61||0.20%<br />
|-<br />
|animation-duration||56||0.19%<br />
|-<br />
|animation-name||56||0.19%<br />
|-<br />
|border-bottom-left-radius||55||0.18%<br />
|-<br />
|border-bottom-right-radius||55||0.18%<br />
|-<br />
|transition-property||49||0.16%<br />
|-<br />
|animation-iteration-count||45||0.15%<br />
|-<br />
|padding-start||45||0.15%<br />
|-<br />
|background-size||43||0.14%<br />
|-<br />
|animation-timing-function||42||0.14%<br />
|-<br />
|box-sizing||42||0.14%<br />
|}<br />
<br />
=== Larger, as-yet-unprocessed datasets ===<br />
* Raw data downloading completed in mid-January 2012, using these UAs:<br />
# latest Android Native Browser from ICS<br />
# latest Mobile Safari UA<br />
* Includes all HTML, Javascript, CSS files in compressed format<br />
* Roughly 1.1m files downloaded for each UA<br />
* CSS file parsing is underway to produce more data</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Auto-tools/Projects/W3C_CSS_Test_Mirroring&diff=362276Auto-tools/Projects/W3C CSS Test Mirroring2011-10-30T01:21:43Z<p>Fantasai: /* More Info */</p>
<hr />
<div>= Rationale =<br />
The W3C CSS Test working group has a bunch of tests in their hg repo on the W3C site. We need an automated way to pull the tests back from the W3C site into our infrastructure so that these tests can be run in addition to the rest of our automated test suites.<br />
<br />
We also need a way to automatically annotate new tests for inclusion into the upstream W3C repo. As a point of process, when a test is submitted to the W3C, it goes into a "submitted" tree, and then once it is accepted it is in an "approved" tree. This is important to remember for the process outlined below.<br />
<br />
= Proposed Process =<br />
* Developer writes test to be synced to W3C - these have a separate license, so they land in the other-licenses/ directory (fantasai will determine the proper directory for this), for now, let's call it other-licenses/w3c-css/submitted<br />
* An hg hook watches for checkins to this directory and causes the new test to be pushed into the W3C "submitted" tree.<br />
* On some time sequence (once a day or something) we pull from the W3C "approved" tree into our other-licenses/w3c-css/received (name TBD) directory.<br />
** When we pull the tests down, we need to generate the reftest manifests for the newly downloaded tests. (Note: W3C has build scripts that can generate reftest manifests.)<br />
** Because these newly downloaded tests may exist in our submitted directory we need to ensure that the reftest manifest annotations those files had in the submitted directory are added to the generated manifest for the new file in the received/ directory.<br />
** Once the manifests are merged, the submitted test files (and their corresponding manifest entries) should be deleted.<br />
<br />
== Other considerations ==<br />
We probably want to sync the W3C tests back into some kind of project branch. This way we can run the automated tests on them and let developers work on them to get them running and passing. The tests may need some specific Gecko reftest manifest annotation or something to get our tests to green. Once we get the tests to green, we can then merge them into mozilla-central. This last merge would be a manual step.<br />
<br />
= Goal =<br />
* Incorporate W3C-hosted CSS reftests into our automated testing framework<br />
* Have a place and process for devs to land tests that should be submitted to W3C<br />
* Keep our copy and W3C's copy of the tests in sync<br />
<br />
= Non-Goal =<br />
* Not to solve every corner case. If the W3C ends up changing the name of the test between the "submitted" and the "accepted" step, we may lose the ability to track the test, and we'll have to deal with that manually.<br />
<br />
= More Info =<br />
* CSSWG test server - http://test.csswg.org/<br />
* CSSWG test wiki - http://wiki.csswg.org/test<br />
* Bug for legal signoff - https://bugzilla.mozilla.org/show_bug.cgi?id=691950<br />
* Questions? Ask [http://fantasai.inkedblade.net/contact fantasai]</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Events&diff=361099Events2011-10-25T23:05:50Z<p>Fantasai: /* November 2011 */</p>
<hr />
<div>= Events =<br />
<br />
Events that Mozillians are speaking at, participating in, attending, or just recommend. In particular events that relate to web [[standards]].<br />
<br />
Feel free to add events you think are of interest to Mozillians and create separate pages for specific events if necessary.<br />
<br />
Please at a minimum document:<br />
* dates/times of the events <br />
* link to the primary page about an event. Random links like "Have a look a this" will get deleted.<br />
<br />
== add events to your calendar ==<br />
iCal, Evolution:<br />
* Subscribe events: http://h2vx.com/ics/sub/wiki.mozilla.org/Events<br />
* Clicking that link will open your local calendar program (e.g. MacOSX iCal, Evolution, etc.)<br />
* Set it to update (i.e. "<nowiki>[x]</nowiki> Refresh" or "Auto-refresh: Every day") and new events will appear automatically.<br />
<br />
Zimbra:<br />
* Choose the "'''Calendar'''" tab<br />
* in the far left column, click the new calendar icon (little mini green calendar with a plus sign, top right corner of the column header)<br />
* a "'''Create New Calendar'''" dialog box appears<br />
* enter something like "MozWiki Events" into the '''Name''' field<br />
* check the 2nd checkbox: '''<nowiki>[x]</nowiki> Synchronize appointments from remote calendar'''<br />
* copy this URL: '''<code><nowiki>http://h2vx.com/ics/wiki.mozilla.org/Events</nowiki></code>''' <br />
* paste it into the '''URL''' field<br />
* click '''<nowiki>[ OK ]</nowiki>''' <br />
<br />
You may also download [http://h2vx.com/ics/wiki.mozilla.org/Events events on this page as an iCalendar file].<br />
<br />
== upcoming ==<br />
Add new and upcoming events here. <br />
<br />
=== October 2011 ===<br />
<div class="vevent"><br />
* <span class="dtstart">2011-10-01</span>...<span class="dtend">2011-10-05</span> <span class="summary">[http://max.adobe.com/ Adobe MAX 2011]</span> at <span class="location vcard"><span class="locality">London</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Robnyman|Robert Nyman]]</span> (<span class="role">speaker</span>)</span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-10-10</span>...<span class="dtend">2011-10-13</span> <span class="summary">[http://www.web2expo.com/webexny2011/ Web 2.0 Expo NYC]</span> at <span class="location vcard"><span class="locality">New York</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="role">speaker</span>)</span> on [http://plancast.com/p/7yeo HTML(5) Now]<br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-10-27</span>...<span class="dtend">2011-10-28</span> <span class="summary">[http://www.tech4africa.com/ TECH4AFRICA]</span> at <span class="location vcard"><span class="locality">Johannesburg</span>, <span class="country-name">South Africa</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Robnyman|Robert Nyman]]</span> (<span class="role">speaker</span>)</span><br />
</div><br />
<br />
=== November 2011 ===<br />
<div class="vevent"><br />
* <span class="dtstart">2011-10-30</span>...<span class="dtend">2011-11-04</span> <span class="summary">[http://www.w3.org/2011/11/TPAC/ W3C TPAC 2011]</span> at <span class="location vcard"><span class="fn">Santa Clara Marriott</span>, <span class="locality">Santa Clara</span>, <span class="region">California</span>, <span class="country-name">U.S.</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="role">co-organizer</span>, <span class="role">speaker</span>, <span class="role">participant</span>)</span> at/in [http://wiki.csswg.org/planning/tpac-2011 CSSWG f2f] (2011-10-30...2011-11-01), Plenary Day (2011-11-02), HTMLWG f2f<br />
** dbaron, fantasai -> @csswg<br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-11-04</span>...<span class="dtend">2011-11-06</span> <span class="summary">[http://lanyrd.com/2011/mozilla-festival/ Mozilla Festival]</span> at <span class="location vcard"><span class="locality">London</span>, <span class="country-name">England</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">Mitchell Baker</span> (<span class="role">speaker</span>)</span><br />
** ...<br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-11-04</span>...<span class="dtend">2011-11-05</span> <span class="summary">[http://www.startechconf.com/ StarTechConf]</span> at <span class="location vcard"><span class="locality">Santiago</span>, <span class="country-name">Chile</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Robnyman|Robert Nyman]]</span> (<span class="role">speaker</span>)</span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-11-15</span>...<span class="dtend">2011-11-16</span> <span class="summary">[http://lanyrd.com/2011/w3conf/ W3Conf: Practical Standards for Web Professionals]</span> at <span class="location adr"><span class="locality">Seattle</span> <abbr class="region" title="Washington">WA</abbr></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="role">speaker</span>)</span> on Browser Vendor panel, "How Do Browsers Implement Standards".<br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-11-17</span> <span class="summary">[http://lanyrd.com/2011/web-analytics-wednesday/ Web Analytics Wednesday]</span> at <span class="location vcard"><span class="fn">Roe</span>, <span class="locality">San Francisco</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="role">attendee</span>)</span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-11-18</span> <span class="summary">[http://lanyrd.com/2011/accelerate/ ACCELERATE 2011]</span> at <span class="location vcard"><span class="fn">Mission Bay Conference Center</span>, <span class="locality">San Francisco</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="role">attendee</span>)</span><br />
</div><br />
<br />
=== December 2011 ===<br />
...<br />
=== January 2012 ===<br />
...<br />
=== February 2012 ===<br />
<div class="vevent"><br />
* <span class="dtstart">2012-02-06</span>...<span class="dtend">2012-02-08</span> <span class="summary">[http://wiki.csswg.org/planning/paris-2012 CSS WG F2F]</span> in <span class="location adr"><span class="locality">Paris</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Dbaron|David Baron]]</span></span><br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span></span><br />
** <span class="attendee vcard"><span class="fn">[[User:Fantasai|fantasai]]</span></span><br />
</div><br />
<br />
=== March 2012 ===<br />
<div class="vevent"><br />
* <span class="dtstart">2012-03-09</span>...<span class="dtend">2012-03-18</span> <span class="summary">[http://lanyrd.com/2012/sxsw-interactive/ SXSW]</span> at <span class="location adr"><span class="locality">Austin</span> <abbr class="region" title="Texas">TX</abbr></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="role">attendee</span>)</span> (Interactive Advisory Board)<br />
** <span class="attendee vcard"><span class="fn">[[User:Dbaron|David Baron]]</span> (<span class="role">speaker</span>)</span> on [http://panelpicker.sxsw.com/ideas/view/12909 Fast CSS: How Browsers Lay out Web Pages] ([http://sxsw.com/node/9580 2011-10-24 announced as on the schedule])<br />
** <span class="attendee vcard"><span class="fn">Dan Sinker</span> (<span class="role">speaker</span>)</span> on [http://panelpicker.sxsw.com/ideas/view/11939 Open Web, Open News: Reporters & Developers Remix] ([http://sxsw.com/node/9580 2011-10-24 announced as on the schedule])<br />
</div><br />
<br />
== past ==<br />
Move upcoming events from above to here when they have completed. As this section grows we can archive past events into sub-pages by year and/or month like Events/2010/07 as necessary etc.<br />
<br />
=== September 2011 ===<br />
<div class="vevent"><br />
* <span class="dtstart">2011-09-02</span>...<span class="dtend">2011-09-04</span> <span class="summary">[http://2011.dconstruct.org/ dConstruct 2011]</span> in <span class="location adr"><span class="locality">Brighton</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span></span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-09-04</span>...<span class="dtend">2011-09-06</span> <span class="summary">[http://websummit.talkweb.eu/ Bulgaria WebSummit]</span> at <span class="location org"><span class="fn org"> Tbc</span>, <span class="adr"><span class="street-address"> Downtown</span>, <span class="locality">Varna</span>, <span class="country-name">Bulgaria</span></span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Bogomil|Bogomil Shopov]] (<span class="role">organizer</span>)</span></span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-09-05</span> <span class="summary">[http://lanyrd.com/2011/updateconf/ Update 2011]</span> in <span class="location adr"><span class="locality">Brighton</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span></span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-09-08</span> <span class="summary">[http://lanyrd.com/2011/adobe-html5-camp/ Adobe HTML5 Camp]</span> in <span class="location adr"><span class="locality">London</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span></span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-09-10</span>...<span class="dtend">2011-09-11</span> <span class="summary">[http://2011.barcampbrighton.org/ BarCampBrighton]</span> in <span class="location adr"><span class="locality">Brighton</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]] (<span class="role">organizer</span>)</span></span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-09-10</span>...<span class="dtend">2011-09-12</span> <span class="summary">[http://openvideoconference.org Open Video Conference]</span> at <span class="location org"><span class="fn org"> New York Law School</span>, <span class="adr"><span class="locality">New York City</span>, <span class="region">New York</span>, <span class="country-name">U.S.</span></span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Benmoskowitz|Ben Moskowitz]] (<span class="role">organizer</span>)</span></span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-09-17</span>...<span class="dtend">2011-09-18</span> <span class="summary">[http://lanyrd.com/2011/wcpdx/ WordCamp Portland]</span> at <span class="location org"><span class="fn org"> Eliot Center</span>, <span class="adr"><span class="street-address">1226 SW Salmon St.</span>, <span class="locality">Portland</span>, <abbr class="region" title="Oregon">OR</abbr> <span class="postal-code">97205</span>, <abbr title="United States" class="country-name">U.S.</abbr></span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]] (<span class="role">speaker</span>)</span></span> / session leader on Web Actions<br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-09-18</span>...<span class="dtend">2011-09-20</span> <span class="summary">[https://thestrangeloop.com/ Strange Loop 2011 Conference]</span> at <span class="location org"><span class="adr"><span class="street-address">Hilton St. Louis at the Ballpark</span>, <span class="locality">St. Louis, MO</span>, <span class="country-name">U.S.</span></span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Allenwb|Allen Wirfs-Brock]] (<span class="role">keynote speaker</span> - on [https://thestrangeloop.com/sessions/post-pc-computing-is-not-a-vision Post-PC Computing is Not a Vision])</span></span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-09-30</span> <span class="summary">UX Brighton (tentative)</span> in <span class="location adr"><span class="locality">Brighton</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="role">speaker</span> - on hypermedia history and influence on more recent hypertext systems)</span><br />
</div><br />
<br />
=== August 2011 ===<br />
<div class="vevent"><br />
* <span class="dtstart">2011-08-31</span> <span class="summary">[http://2011.dconstruct.org/workshops/jeremy-keith dConstruct 2011 workshop: Responsive Enhancement]</span> in <span class="location adr"><span class="locality">Brighton</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span></span><br />
</div><br />
<br />
=== July 2011 ===<br />
<div class="vevent"><br />
* <span class="dtstart">2011-07-09</span> <span class="summary">[http://www.gothamjs.com/ GothamJS]</span> at <span class="location vcard"><span class="locality">New York City</span>, <span class="country-name">United States</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Robnyman|Robert Nyman]]</span> (<span class="role">speaker</span>)</span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-07-16</span> <span class="summary">[http://openwebcamp.org/ Open Web Camp III]</span> at <span class="location vcard"><span class="locality">Stanford</span>, <span class="region">California</span>, <span class="country-name">United States</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="role">speaker</span> - on [http://openwebcamp.org/events/1 CASSIS])</span><br />
** <span class="attendee vcard"><span class="fn">Christian Heilmann</span> (<span class="role">speaker</span> - on [http://openwebcamp.org/events/4 HTML5 battles still to be won!])</span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-07-23</span> <span class="summary">[http://www.w3.org/2002/09/wbs/47318/webrtc-f2f-quebec/ WebRTC WG F2F]</span> in <span class="location adr"><span class="locality">Quebec City, Canada</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tterribe|Timothy B. Terriberry]]</span></span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-07-24</span>...<span class="dtend">2011-07-29</span> <span class="summary">[http://www.ietf.org/meeting/81/ IETF 81]</span> in <span class="location adr"><span class="locality">Quebec City, Canada</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tterribe|Timothy B. Terriberry]]</span></span><br />
** <span class="attendee vcard"><span class="fn">[[User:Jmvalin|Jean-Marc Valin]]</span></span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-07-24</span>...<span class="dtend">2011-07-26</span> <span class="summary">[http://wiki.csswg.org/planning/seattle-2011 CSS WG F2F]</span> in <span class="location adr"><span class="locality">Seattle</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Dbaron|David Baron]]</span></span><br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span></span><br />
** <span class="attendee vcard"><span class="fn">[[User:Fantasai|fantasai]]</span></span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-07-25</span>...<span class="dtend">2011-07-29</span> <span class="summary">[http://www.oscon.com/oscon2011/ OSCON]</span> in <span class="location adr"><span class="locality">Portland</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span></span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-07-30</span> <span class="summary">[http://lanyrd.com/2011/api-hackday-pdx/ API Hackday PDX]</span> in <span class="location adr"><span class="locality">Portland</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span></span><br />
</div><br />
<br />
=== June 2011 ===<br />
<div class="vevent"><br />
* <span class="dtstart">2011-06-04</span>...<span class="dtend">2011-06-05</span> <span class="summary">[http://opencamp.talkweb.eu/ OpenCamp]</span> at <span class="location org"><span class="fn org"> Tbc</span>, <span class="adr"><span class="street-address"> Downtown</span>, <span class="locality">Sofia</span><span class="country-name">Bulgaria</span></span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Bogomil|Bogomil Shopov]]</span> (<span class="role">organizer</span>)</span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-06-11</span>...<span class="dtend">2011-06-11</span> <span class="summary">[http://swdc-central.com/androidonly2011malmo/index.html/ Android Only Malmö]</span> in <span class="locality">Stockholm</span>, <span class="country-name">Sweden</span></span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">Brad Lassey</span> (<span class="role">speaker</span>)</span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-06-14</span>...<span class="dtend">2011-06-15</span> <span class="summary">[http://2011.texasjavascript.com/ TXJS, Texas JavaScript]</span> at <span class="location org"><span class="fn org">Alamo Drafthouse</span>, <span class="adr"><span class="street-address"></span>, <span class="locality">Austin, TX </span> <span class="country-name">USA</span></span></span>. Mozilla is sponsoring. Contact Stormy Peters by May 20th for an attendee pass. Attendees:<br />
** <span class="attendee vcard"><span class="fn">Brendan Eich</span> (<span class="role">speaker</span>)</span><br />
** <span class="attendee vcard"><span class="fn">Margaret Leibovic</span> (<span class="role">attendee</span>)</span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-06-21</span>...<span class="dtend">2011-06-24</span> <span class="summary">[http://opensourcebridge.org/ OSBridge]</span> at <span class="location org"><span class="fn org"> Eliot Center</span>, <span class="adr"><span class="street-address"> Downtown</span>, <span class="locality">Portland</span> <span class="region">OR</span></span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="role">attendee</span>)</span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-06-25</span>...<span class="dtend">2011-06-26</span> <span class="summary">[http://plancast.com/p/3cos IndieWebCamp]</span> at <span class="location org"><span class="fn org">TBD</span>, <span class="adr"><span class="street-address"> TBD</span>, <span class="locality">Portland</span> <span class="region">OR</span></span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="role">organizer</span>)</span><br />
</div><br />
<br />
=== May 2011 ===<br />
<div class="vevent"><br />
* <span class="dtstart">2011-05-02</span>...<span class="dtend">2011-05-03</span> <span class="summary">[http://2011.jsconf.us/ JSConf]</span> at <span class="location org"><span class="fn org">Portland Art Museum</span>, <span class="adr"><span class="street-address">1219 SW Park Avenue</span>, <span class="postal-code">97205</span> <span class="locality">Portland, Oregon</span> <span class="country-name">US</span></span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">Allen Wirfs-Brock</span></span><br />
** <span class="attendee vcard"><span class="fn">Brian Brennan</span></span><br />
** <span class="attendee vcard"><span class="fn">Kevin Dangoor</span></span><br />
** <span class="attendee vcard"><span class="fn">Brendan Eich</span></span><br />
** <span class="attendee vcard"><span class="fn">Dave Herman</span></span><br />
** <span class="attendee vcard"><span class="fn">Les Orchard</span></span><br />
** <span class="attendee vcard"><span class="fn">Stormy Peters</span></span><br />
** <span class="attendee vcard"><span class="fn">Patrick Walton</span></span><br />
** <span class="attendee vcard"><span class="fn">Philipp von Weitershausen</span></span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-05-09</span> <span class="summary">[http://www.sfmusictech.com/ SF MusicTech Summit]</span> at <span class="location org"><span class="fn org">Hotel Kabuki</span>, <span class="adr"><span class="street-address">1625 Post Street</span>, <span class="locality">San Francisco</span>, <span class="region">CA</span> <span class="postal-code">94115</span>, <span class="country-name">USA</span></span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span> (speaker HTML5 Audio / Firefox Audio APIs demo, <span class="role">attendee</span>)</span> (demos/presentation: [[Audio]])<br />
** <span class="attendee vcard"><span class="fn">Dan Mosedale</span> (<span class="role">attendee</span>)</span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-05-18</span>...<span class="dtend">2011-05-20</span> <span class="summary">[http://falsyvalues.com/ Falsy Values]</span> at <span class="location org"><span class="fn org">GOLDEN FLOOR ATRIUM</span>, <span class="adr"><span class="street-address">al. Jana Pawła II 27</span>, <span class="postal-code">00-867</span> <span class="locality">Warsaw</span> <span class="country-name">Poland</span></span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span> (speaker 5-19 HTML5/CSS3 workshop and 5-20 CASSIS.js, <span class="role">attendee</span>)</span><br />
** <span class="attendee vcard"><span class="fn">[[User:Gandalf|Zbigniew Braniecki]]</span> (speaker 5-20 JavaScript JIT, <span class="role">attendee</span>)</span><br />
<br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-05-21</span> <span class="summary">[http://www.ukuug.org/events/opentech2011/ OpenTech 2011]</span> at <span class="location vcard"><span class="fn org">University of London Union</span>, <span class="adr"><span class="street-address">Malet Street</span>, <span class="locality">London</span> <span class="postal-code">WC1E 7HY</span>, <span class="country-name">England</span></span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="role">attendee</span>)</span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-05-23</span> <span class="summary">[http://concise-conferences.com/1/20110523-html5.html How HTML5 Will Change the Web]</span> at <span class="location vcard"><span class="fn org">Online</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Robnyman|Robert Nyman]]</span> (<span class="role">speaker</span>)</span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-05-24</span>...<span class="dtend">2011-05-25</span> <span class="summary">[http://www.w3.org/2011/identity-ws/ W3C Workshop on Identity in the Browser]</span> (#idbrowser) at <span class="location org"><span class="fn org">Mozilla</span>, <span class="adr"><span class="street-address">650 Castro st.</span>, <span class="locality">Mountain View</span> <span class="region">CA</span></span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Thunder|Dan Mills]]</span> (<span class="role">organizer</span>, <span class="role">speaker</span>)</span><br />
** <span class="attendee vcard"><span class="fn">Michael Hanson</span> (<span class="role">organizer</span>, <span class="role">speaker</span>)</span><br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="role">attendee</span>, <span class="role">speaker</span> - see [[identity-inputs]])</span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-05-25</span> <span class="summary">[http://www.valtech.se/techdays/ Valtech Tech Days]</span> at <span class="location vcard"><span class="locality">Stockholm</span>, <span class="country-name">Sweden</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Robnyman|Robert Nyman]]</span> (<span class="role">speaker</span>)</span><br />
</div><br />
<br />
<br />
=== April 2011 ===<br />
<div class="vevent"><br />
* <span class="dtstart">2011-04-09</span>...<span class="dtend">2011-04-10</span> <span class="summary">[http://linkedgov.hackcamp.org.uk/pages/where-and-when/ LinkedGov Data HackCamp]</span> at <span class="location org"><span class="fn org"> LBi</span>, <span class="adr"><span class="street-address"> Brick Lane</span>, <span class="locality">London</span>, <span class="country-name">England</span></span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="role">attendee</span> 2011-04-10 only)</span><br />
</div><br />
<div class="vevent"><br />
* <span class="dtstart">2011-04-13</span>...<span class="dtend">2011-04-15</span> <span class="summary">[http://2011.uxlondon.com/ UX London]</span> at <span class="location org"><span class="fn org">Cumberland Hotel</span>, <span class="adr"><span class="street-address">Marble Arch</span>, <span class="locality">London</span>, <span class="country-name">England</span></span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="role">attendee</span>)</span><br />
</div><br />
<div class="vevent"><br />
* <span class="dtstart">2011-04-19</span>...<span class="dtend">2011-04-21</span> <span class="summary">[http://where2conf.com/where2011 Where 2.0]</span> at <span class="location org"><span class="fn org">Santa Clara Convention Center</span>, <span class="adr"><span class="street-address">5001 Great America Parkway</span>, <span class="locality">Santa Clara</span> <span class="region">CA</span></span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="role">attendee</span>)</span><br />
** <span class="attendee vcard"><span class="fn">Ryan Doherty</span> (<span class="role">attendee</span>)</span><br />
</div><br />
<div class="vevent"><br />
* <span class="dtstart">2011-04-22</span>...<span class="dtend">2011-04-23</span> <span class="summary">[https://www.socialtext.net/wherecamp/wherecampsf_sf_2011 WhereCampSF SF 2011]</span> at <span class="location org"><span class="fn org">Stanford Alumni Center</span>, <span class="adr"><span class="street-address">326 Galvez Street</span>, <span class="locality">Stanford</span> <span class="region">CA</span></span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="role">attendee</span> 2011-04-22 only)</span><br />
</div><br />
<br />
=== March 2011 ===<br />
<div class="vevent"><br />
* <span class="dtstart">2011-03-07</span>...<span class="dtend">2011-03-09</span> <span class="summary">[http://wiki.csswg.org/planning/mountain-view-2011 CSS Working Group March 2011 meeting]</span> at <span class="location org"><span class="fn org">Mozilla</span>, <span class="adr"><span class="street-address"> 650 Castro street</span>, <span class="locality">Mountain View</span> <span class="region">CA</span></span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Dbaron|David Baron]] </span> (<span class="role">organizer</span>)</span><br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]] </span></span><br />
** <span class="attendee vcard"><span class="fn">John Daggett</span></span><br />
** <span class="attendee vcard"><span class="fn">[[User:Fantasai|fantasai]]</span></span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-03-10</span>...<span class="dtend">2011-03-20</span> <span class="summary">[http://2011.sxsw.com SXSW]</span> at <span class="location org"><span class="fn org">Austin Convention Center</span>, <span class="adr"><span class="street-address"> 500 E Cesar Chavez St.</span>, <span class="locality">Austin</span> <span class="region">TX</span></span></span>. Wiki page: <span class="url">https://wiki.mozilla.org/Event:SXSW_Interactive_2011</span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="role">panelist</span> on: "The Future of Microformats" 2011-03-14)</span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2011-03-28</span>...<span class="dtend">2011-03-31</span> <span class="summary">[http://www.web2expo.com/webexsf2011/ Web 2.0 Expo]</span> at <span class="location org"><span class="fn org">Moscone West</span>, <span class="adr"><span class="street-address"> 4th street</span>, <span class="locality">San Francisco</span> <span class="region">CA</span></span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="role">speaker</span> on 2011-03-29: "[http://www.web2expo.com/webexsf2011/public/schedule/detail/19758 HTML(5) Now]" and "[http://www.web2expo.com/webexsf2011/public/schedule/detail/19987 Controversies of HTML5]")</span><br />
</div><br />
<br />
=== February 2011 ===<br />
* 2011-02-14: ID Collab Day in SF ([http://idcolab.eventbrite.com/ site])<br />
** Dan Mills (planning to attend)<br />
<br />
=== November 2010 ===<br />
<div class="vevent"><br />
* <span class="dtstart">2010-11-01</span> <span class="summary">[http://plancast.com/p/2lpp OpenID Technology Summit]</span> at <span class="location vcard"><span class="fn org">Facebook</span> Headquarters, <span class="adr"><span class="locality">Palo Alto</span></span></span>. Also on [http://www.facebook.com/event.php?eid=158146954217324 Facebook]. Participants:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span></span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2010-11-08</span>...<span class="dtend">2010-11-10</span> <span class="summary">[http://yuilibrary.com/yuiconf2010/ YUIConf]</span> at <span class="location org"><span class="fn org">Yahoo</span>, <span class="adr"><span class="street-address">701 First Ave</span>, <span class="locality">Sunnyvale</span> <span class="region">CA</span></span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="role">speaker</span>: "HTML5: Right Here, Right Now" 2010-11-09 16:30, and <span class="role">panelist</span> on: "The Future of Web Development" 2010-11-09 18:30)</span><br />
</div><br />
<br />
=== October 2010 ===<br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2010-10-01</span>...<span class="dtend">2010-10-02</span> <span class="summary">[http://www.openvideoconference.org/ Open Video Conference]</span> in <span class="location adr"><span class="locality">New York City</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Blizzard|Chris Blizzard]]</span> (<span class="role">track organizer - Oct 1 morning HTML5 sessions</span>)</span><br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="role">participant</span>)</span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2010-10-03</span> <span class="summary">OVC hack labs</span> at <span class="location vcard"><span class="fn org">NYU Interactive Telecommunications Program</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Blizzard|Chris Blizzard]]</span> (<span class="role">mentor</span>)</span><br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="role">mentor</span>)</span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2010-10-08</span>...<span class="dtend">2010-10-09</span> <span class="summary">[http://openwebfoo10.wiki.oreilly.com/wiki/ Open Web Foo]</span> in <span class="location adr"><span class="locality">Sebastopol</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:mitchell|Mitchell Baker]]</span> (<span class="role">participant</span>)</span><br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="role">participant</span>)</span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2010-10-21</span>...<span class="dtend">2010-10-22</span> <span class="summary">[http://front-trends.com/ Front Trends conference]</span> in <span class="location adr"><span class="locality">Warsaw</span>, <span class="country-name">Poland</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="role">speaker</span>: "HTML5: Right Here, Right Now")</span><br />
</div><br />
<br />
<br />
=== September 2010 ===<br />
<div class="vevent"><br />
* <span class="dtstart">2010-09-01</span>...<span class="dtend">2010-09-03</span> <span class="summary">[http://2010.dConstruct.org/ dConstruct 2010]</span> in <span class="location adr"><span class="locality">Brighton</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span></span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2010-09-09</span> <span class="summary">[http://plancast.com/p/27av MozPub HTML5 meet, with Tantek Çelik]</span> in <span class="location adr"><span class="locality">Brighton</span></span>. Also on [http://lanyrd.com/2010/mozpub-brighton/ Lanyrd] and [http://www.meetup.com/Mozilla-Labs/calendar/14681695/ MeetUp]. Follow [http://twitter.com/mozpub @mozpub] for more. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span></span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2010-09-21</span>...<span class="dtend">2010-09-25</span> <span class="summary">[http://usa10.webdirections.org/ Web Directions USA]</span> in <span class="location adr"><span class="locality">Atlanta</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="role">speaker</span>)</span><br />
*** <span class="vevent">Panelist on "<span class="summary">The Open Web Landscape</span>", <span class="dtstart"><span class="value">2010-09-23</span> from <span class="value">4:05pm</span></span>-<span class="dtend"><span class="value">5:05pm</span></span>.</span><br />
*** <span class="vevent">Mentor for "<span class="summary">Amped Hack Day</span>" (<span class="url">http://ampedweb.org/</span>), <span class="dtstart">2010-09-25</span>.</span><br />
</div><br />
<br />
<br />
<br />
=== August 2010 ===<br />
<div class="vevent"><br />
* <span class="dtstart">2010-08-17</span> <span class="summary">[http://www.w3.org/Fonts/WG/ W3C Fonts WG f2f]</span> at Typecon 2010 in <span class="location adr"><span class="locality">LA</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">John Daggett</span></span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2010-08-23</span>...<span class="dtend">2010-08-25</span> <span class="summary">[http://www.w3.org/Style/Group/2010/Oslo W3C CSS WG f2f]</span> in <span class="location adr"><span class="locality">Oslo</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Dbaron|David Baron]] </span></span><br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]] </span></span><br />
** <span class="attendee vcard"><span class="fn">John Daggett</span></span><br />
** <span class="attendee vcard"><span class="fn">[[User:Fantasai|fantasai]]</span></span><br />
</div><br />
<br />
=== July 2010 ===<br />
<div class="vevent"><br />
* <span class="dtstart">2010-07-17</span> <span class="summary">[http://openwebcamp.org OpenWebCamp II]</span> at <span class="location adr"><span class="locality">Stanford</span>, <span class="region">CA</span></span>. Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="role">speaker</span>)</span><br />
** <span class="attendee vcard"><span class="fn">[[User:Thunder|Dan Mills]] </span></span><br />
** <span class="attendee vcard"><span class="fn">Sara Yap</span></span><br />
</div><br />
<br />
<div class="vevent"><br />
* <span class="dtstart">2010-07-18</span> <span class="summary">[http://federatedsocialweb.net/wiki/Main_Page Federated Social Web Summit]</span> at <span class="location adr"><span class="locality">Portland</span></span> ([http://federatedsocialweb.net/wiki/Schedule schedule], [http://status.net/2010/06/28/federated-social-web-summit-2010-announced announcement], [http://federatedsocialweb.net/wiki/FedAll2010/Invitations attendees]). Attendees:<br />
** <span class="attendee vcard"><span class="fn">[[User:Tantek|Tantek Çelik]] </span> (<span class="role">presenter</span>)</span><br />
** <span class="attendee vcard"><span class="fn">[[User:Thunder|Dan Mills]] </span> (<span class="role">presenter</span>)</span><br />
</div><br />
<br />
== sponsorships ==<br />
Want Mozilla to sponsor a conference (or sponsor you to attend a conference)?<br />
<br />
See http://nx3.go.ly/events/checklist<br />
<br />
If you have questions about sponsorship, send them to [dev-events at mozilla dot com].</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Auto-tools/Projects/W3C_CSS_Test_Mirroring&diff=348962Auto-tools/Projects/W3C CSS Test Mirroring2011-09-17T00:02:34Z<p>Fantasai: tweak some names and details, add links</p>
<hr />
<div>= Rationale =<br />
The W3C CSS Test working group has a bunch of tests in their hg repo on the W3C site. We need an automated way to pull the tests back from the W3C site into our infrastructure so that these tests can be run in addition to the rest of our automated test suites.<br />
<br />
We also need a way to automatically annotate new tests for inclusion into the upstream W3C repo. As a point of process, when a test is submitted to the W3C, it goes into a "submitted" tree, and then once it is accepted it is in an "approved" tree. This is important to remember for the process outlined below.<br />
<br />
= Proposed Process =<br />
* Developer writes test to be synced to W3C - these have a separate license, so they land in the other-licenses/ directory (fantasai will determine the proper directory for this), for now, let's call it other-licenses/w3c-css/submitted<br />
* An hg hook watches for checkins to this directory and causes the new test to be pushed into the W3C "submitted" tree.<br />
* On some time sequence (once a day or something) we pull from the W3C "approved" tree into our other-licenses/w3c-css/received (name TBD) directory.<br />
** When we pull the tests down, we need to generate the reftest manifests for the newly downloaded tests. (Note: W3C has build scripts that can generate reftest manifests.)<br />
** Because these newly downloaded tests may exist in our submitted directory we need to ensure that the reftest manifest annotations those files had in the submitted directory are added to the generated manifest for the new file in the received/ directory.<br />
** Once the manifests are merged, the submitted test files (and their corresponding manifest entries) should be deleted.<br />
<br />
== Other considerations ==<br />
We probably want to sync the W3C tests back into some kind of project branch. This way we can run the automated tests on them and let developers work on them to get them running and passing. The tests may need some specific Gecko reftest manifest annotation or something to get our tests to green. Once we get the tests to green, we can then merge them into mozilla-central. This last merge would be a manual step.<br />
<br />
= Goal =<br />
* Incorporate W3C-hosted CSS reftests into our automated testing framework<br />
* Have a place and process for devs to land tests that should be submitted to W3C<br />
* Keep our copy and W3C's copy of the tests in sync<br />
<br />
= Non-Goal =<br />
* Not to solve every corner case. If the W3C ends up changing the name of the test between the "submitted" and the "accepted" step, we may lose the ability to track the test, and we'll have to deal with that manually.<br />
<br />
= More Info =<br />
* CSSWG test server - http://test.csswg.org/<br />
* CSSWG test wiki - http://wiki.csswg.org/test<br />
* Questions? Ask [http://fantasai.inkedblade.net/contact fantasai]</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Websites/Guides/Style&diff=332589Websites/Guides/Style2011-07-23T01:10:30Z<p>Fantasai: /* Page Code */</p>
<hr />
<div>= mozilla.org Style Guide =<br />
<br />
by Jamie Zawinsky and fantasai<br />
<br />
Here are some basic style guidelines for writing content to be hosted on mozilla.org. Some are important, some are arbitrary, but please follow these guidelines in the name of consistency.<br />
<br />
== Adding Files ==<br />
<br />
=== Filenames ===<br />
<br />
'''Use descriptive file names.''' The ideal filename is succinct, specific enough to be descriptive, but general enough to accommodate change or expansion (e.g. becoming a folder). Don't just copy the page's title, as it isn't always appropriate for a filename.<br />
<br />
'''Avoid abbrev.''' It makes the URL that much harder to read and remember. We are not limited to 8.3 names, so make the file names as long as necessary (and no longer).<br />
<br />
'''Don't use page/part numbers.''' Don't name Chapter 4 <code>ch4</code>, because someday you may want to insert another chapter between Chapter 3 and Chapter 4. Name it after the chapter's title instead; this is also more descriptive. The only numbers in filenames should be dates and application version numbers.<br />
<br />
'''Filenames are lowercase.''' It makes URLs consistent throughout the site, and it's easier to remember the URL when case isn't an issue. The exception is documenting code: a doc on <code>nsFoo</code> should be <code>nsFoo.html</code>, not <code>nsfoo.html</code>, to match the code's casing. In no event should you have two files in the same directory that differ only in case: don't have <code>Foo</code> and <code>FOO</code>.<br />
<br />
'''Hyphenate.''' Don't use StudlyCaps to separate words. You can't use uppercase anyway. Use hyphens. Don't use underscores to separate words; underscores don't show up in underlined text.<br />
<br />
'''Don't use funny characters in file names.''' Stick to alphanumerics and hyphen. Our server is a Unix machine, and life gets somewhat more difficult if you use files with spaces, ampersands, quotes, and so on in their names. <code>this-and-that</code> is good. <code>This&That.HTM</code> is bad. You will royally screw anyone using a Macintosh (and Windows, I think) if you use colons, so don't do that.<br />
<br />
'''Avoid redundancy; don't over-qualify.''' <code>dom/domref/dom-window-ref</code> is too much—<code>dom/reference/window</code> is better.<br />
<br />
=== Location ===<br />
<br />
'''Pick (or create) the most logical location for the document.''' Get a feel for the site's organization and fit the document where it most belongs. Look at the site through it's tree structure rather than through the site navigation to get a better idea of where things go. The URI you're assigning to that file is more or less permanent, so it has to be forwards-compatible.<br />
<br />
'''Use subfolders.''' If you have a few files that belong together, or if you expect to, make a subfolder that contains all the related files.<br />
<br />
'''A file's images go in its folder.''' Don't create an "images" folder. For example, a <code>roadmap/</code> (<code>roadmap/index.html</code>) would put its diagram at <code>roadmap/diagram</code>. If the same image is used in several pages, then put it in the deepest common folder.<br />
<br />
=== Linking, Anchors, and URLs ===<br />
<br />
'''Don't point to index.html directly.''' Point to the directory rather than the <code>index.html</code> file. (Include the trailing slash.)<br />
<br />
'''Use relative links whenever practical.''' This reflects the relationship between the two documents, and the link won't break if, for instance, someone copies the documents to a test site.<br />
<br />
'''Use id="anchor-name" for intra-page anchors.''' Also, anchors should, like filenames, be lower case.<br />
<br />
'''Anchors should not be empty.''' They should enclose some relevant fragment of text. For example, to create an anchor for a section add the id attribute to the enclosing section or div tag (if there is one) or to the heading tag itself (if there isn't). If this is done right, styling the anchoring element can be a meaningful and useful styling.<br />
<br />
== Code ==<br />
=== Code Format ===<br />
<br />
'''Use UTF-8.''' Use HTML named entities or Unicode numerical codes for escapes, like &amp;#8212; or &amp;mdash; for an em dash. Do not use references to Windows CP1252 code points even if they appear to work. That is, do not use &#151; for em dash (or any other references to the 128…159 range).<br />
<br />
'''Use short lines.''' Some HTML editors like to produce documents that only insert line breaks in the HTML source at the ends of paragraphs. Don't do that. Use editors that give the HTML source sensibly short lines. If every paragraph is one long line, then diff is mostly useless (since diff is line-oriented.) Also there's always the chance that some random Unix utility is going to blow a buffer. Don't go there.<br />
<br />
'''Lowercase is preferred''' (but not required) for HTML tags and attributes.<br />
<br />
'''Don't use &amp;nbsp; unnecessarily.''' The fact of life of HTML is that sentences don't end in two spaces. Accept it. Don't try to work around it by using &nbsp;. Corollary: use <code>&lt;pre&gt; if you need to; not <code>&lt;tt&gt;</code> and a bucketful of non-breaking spaces. <br />
<br />
=== Validation ===<br />
<br />
'''All new pages should validate as HTML 4.01 Strict or HTML5''' using the [http://validator.w3.org/ W3C Validator]. This ensures that the page doesn't have syntax errors, that it can be processed by all sorts of more obscure browsers, and that it doesn't use the presentational markup deprecated in HTML 4.0. Also, we're making one of the most standards-compliant browsers around. It would be bad show to have an incompliant website.<br />
<br />
=== Markup ===<br />
<br />
'''''Use semantic markup.''''' Semantic markup explains why something should be styled rather than how it should be styled. This lets different style sheets and different browsers present the same idea differently and still be correct. <code>&lt;p&gt;</code>, <code>&lt;code&gt;</code>, and <code>&lt;em&gt;</code> are semantic elements. <code>&lt;b&gt;</code> and <code>&lt;i&gt;</code> are not. Stylistic information belongs in the style sheet, not the markup. Nearly everything else is corollary. So:<br />
<br />
*Presentational markup is ''discouraged'' on mozilla.org even if it's allowed in HTML 4.01 Strict.<br />
*Use <code>&lt;p&gt;</code> to ''enclose'' paragraphs, not <code>&lt;br&gt;</code> or <code>&lt;p&gt;</code> to separate them.<br />
*Use [http://www.w3.org/TR/html4/struct/global.html#h-7.5.5 Headings] for headings, not an arbitrary combination of <code>&lt;b&gt;</code>, <code>&lt;big&gt;</code>, <code>&lt;hr&gt;</code>, and/or CSS.<br />
*Don't use tables for layout. Tables are for tabular data. Text columns are not tabular data.<br />
<br />
Recommended Reading: [http://www.oasis-open.org/docbook/documentation/reference/html/ch01.html#AEN367 Structured and Semantic Markup] from <cite>DocBook: The Definitive Guide</cite> (in Chapter 1) It's about 5 pages in the print version (4 pages printed), and worth the few minutes it takes to read.<br />
<br />
=== Adding Style ===<br />
<br />
Stylistic information is centralized into several site-wide style sheets. This way, the site has a coherent look and feel and the formatting conventions are consistent. Reuse the site's markup conventions. If there's a commonly-used construct that's missing from the global style sheets, file a bug to add it there instead of working around the deficiency in your corner of the site.<br />
<br />
However, the site style sheets can't handle everything, so some pages may need to incorporate additional rules for local use or to handle specific page layouts. If that's the case with you:<br />
<br />
'''Don't depend on any particular presentation for an element or class.''' Our content outlasts our site designs. You can depend on a set of sensible style rules, but don't depend on, e.g. all filenames being rendered in a monospaced font. A style might decide to make them italic serif.<br />
<br />
'''No inline styles.''' The style attribute is banned from mozilla.org pages with two exceptions: float and clear. Use semantic markup and either <link>ed style sheets or <style>.<br />
<br />
'''Share common styles.''' If the same rules are used on more than one page, but not globally, put them in a separate style sheet file placed in the deepest folder common to those files.<br />
<br />
'''Avoid creating presentational classes.''' class="center" is no better than align="center".<br />
<br />
'''Do not set font-family.''' The font is handled by site style sheets. Other font properties are allowed, but don't change the font for the entire page (e.g. don't set <code>font-size: small</code> on <code>&lt;body&gtl;</code>).<br />
<br />
'''Avoid setting any colors''' on individual pages. If for some reason you need to set specific colors:<br />
<br />
*Make sure you reset all the element's children as well. <br />
*Make color rules <code>!important</code>.<br />
*Never set a text color without also setting a background color, and vice versa.<br />
*Use the <code>background</code> shorthand property, not <code>background-color</code> or <code>background-image</code>.<br />
*If you're using a background image, also set a matching background color. <br />
<br />
.class {<br />
color: black !important;<br />
background: gray url(slate.gif) !important;<br />
}<br />
.class * {<br />
color: inherit !important;<br />
background: transparent !important;<br />
}<br />
<br />
'''Pages must be legible in NS4+, MSIE6+, and Mozilla, with or without CSS or JS.''' We're trying to upgrade the Web here. Don't block the dark forgotten reaches who haven't seen the light of the latest shiny, or have access problems and are jumping through hoops to reach us. It doesn't have to be pretty, but it has to work.<br />
<br />
'''Make sure multiple window sizes work.''' Resize the window, both narrow and wide. (No, ''really'' narrow: 900 pixels is not narrow, it's normal.) Another common mistake made by people using HTML editors is the presence of random <code>&lt;br&gt;</code> tags at the ends of lines.<br />
<br />
== Content ==<br />
<br />
=== Writing Form ===<br />
<br />
'''Avoid all caps.''' If the uppercase is used for style (e.g. for emphasis), let the style sheet handle it. If you are talking about <code>SOME_RANDOM_C_TOKEN</code>, make sure you mark it with <code>&lt;code&gt;</code>.<br />
<br />
'''mozilla.org''' is spelled in lowercase. The name of the application is Mozilla. It is a proper noun, and is therefore capitalized. The name of the organization is mozilla.org. It is a host name, and therefore, is lowercase. Even if it is at the beginning of a sentence, it should always be lowercase. If it bothers you to begin a sentence with a lowercase word, rephrase the sentence. (It's not hard.) Never type Mozilla.org.<br />
<br />
'''Use proper capitalization for titles and headings.''' This keeps capitalization consistent throughout mozilla.org. Also, although CSS can manipulate case, it can't do proper capitalization—so that needs to be written in.<br />
<br />
'''Use a spell checker.''' Say no more.<br />
<br />
=== Writing Style ===<br />
<br />
'''Eschew marketing obfuscation.''' These are technical documents, folks. One of the things that people seem to like best about the existing content on mozilla.org is that it is written by people, for people, without bluster or self-promotion.<br />
<br />
When describing something, don't tell people how great it is. Don't tell them how useful it is. Tell them what it does. Tell them what it's for.<br />
<br />
Don't use buzzwords. Instead, say what you mean. Never use a long word where a short one would do. If it's possible to cut a word out, cut it out.<br />
<br />
Read George Orwell's Politics and the English Language. Read it again. Have it tattooed on the inside of your eyelids.<br />
<br />
'''Separate technical and religious topics.''' It is ok to publish documents which advocate potentially controversial ideas or approaches. However, it is generally better if such advocacy not be in the same document as technical information. For example, a document explaining what you have to do in order to successfully use C++ is a good thing; and a document arguing that you should not use C++ is also a good thing; however, they should not be the same document, because the controversial part might cause the readers to disregard the factual, non-controversial part, and miss out on important information.<br />
<br />
'''Speak for yourself.''' You don't speak for mozilla.org. Don't make promises about what mozilla.org will or will not do in the future. Hedge your bets with words like might or (sometimes) probably.<br />
<br />
Be careful with the word we. It would be bad if you made some assertion about what mozilla.org (as a whole) believes or desires or likes, only to find that there are others in the organization who disagree.<br />
<br />
Also, if you are employed to work on Mozilla, keep in mind that you likely wear two hats: your company hat, where you are concerned with shipping branded software; and your mozilla.org hat, where you are concerned with shipping source code on which other developers can base their own works. These two jobs are not the same, and you should be careful not to conflate the two.<br />
<br />
'''Don't play lawyer.''' Sometimes you may find yourself writing something about what is or is not allowed by the terms of the NPL, MPL, or some other license. Be very, very careful. It's probably best to say nothing at all, but if you must, you should defer to the authority of the license itself. Unless you actually are a lawyer, you're not qualified to interpret what it says, and you don't want to inadvertently say something that might get either mozilla.org or your employer into trouble.</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Websites/Guides&diff=332571Websites/Guides2011-07-22T23:42:41Z<p>Fantasai: /* Existing Guides */ port style guide to wiki since it's been archived</p>
<hr />
<div>A list of existing guides and references that can be used by any existing Mozilla website or by anyone interested in creating a new Mozilla website.<br />
<br />
=Existing Guides=<br />
<br />
* [https://wiki.mozilla.org/MCS Mozilla Community Sites Project]<br />
* [[Websites/Guides/Style|mozilla.org Style Guide]]<br />
* [[Websites/Guides/Templates|Mozilla site design templates]]<br />
* [http://support.mozilla.com/en-US/kb/Style+Guide SUMO Style Guide]<br />
* [https://wiki.mozilla.org/L10n:Localizability/Web Web Localization Guide]<br />
* [http://www.mozilla.com/en-US/about/logo/ Firefox Logo Guide]<br />
* [http://www.mozilla.org/foundation/identity-guidelines/ Mozilla Foundation Visual Identity Guidelines]<br />
* [https://developer.mozilla.org/Project:en/Writer%27s_guide developer.mozilla.org Writer's Guide]<br />
* [https://intranet.mozilla.org/MozillaStyleGuide Press Style Guide]<br />
* [[WebDev:FrontendCodeStandards|Front End Code Standards]]<br />
* [[WebAppSec/Secure_Coding_Guidelines|Secure Coding Guidelines]]<br />
* [[QA/Execution/Web_Testing/Project_Checklist|Web Testing Project Checklist]]<br />
* [[Webdev:Flux:Steward_Guidelines|Webdev:Flux:Steward Guidelines]]<br />
<br />
''Note: these existing guides were largely created for use by a single site or by a small collection of sites. Some of these may be worth expanding to cover sites in general.''<br />
<br />
=Guide Wishlist=<br />
<br />
* New Website Checklet<br />
* Guide for starting a new open source site project</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Websites/Guides/Style&diff=332568Websites/Guides/Style2011-07-22T23:35:05Z<p>Fantasai: Port style guide from www.mozilla.org to wiki so it's not exiled to the archives.</p>
<hr />
<div>= mozilla.org Style Guide =<br />
<br />
by Jamie Zawinsky and fantasai<br />
<br />
Here are some basic style guidelines for writing content to be hosted on mozilla.org. Some are important, some are arbitrary, but please follow these guidelines in the name of consistency.<br />
<br />
== Adding Files ==<br />
<br />
=== Filenames ===<br />
<br />
'''Use descriptive file names.''' The ideal filename is succinct, specific enough to be descriptive, but general enough to accommodate change or expansion (e.g. becoming a folder). Don't just copy the page's title, as it isn't always appropriate for a filename.<br />
<br />
'''Avoid abbrev.''' It makes the URL that much harder to read and remember. We are not limited to 8.3 names, so make the file names as long as necessary (and no longer).<br />
<br />
'''Don't use page/part numbers.''' Don't name Chapter 4 <code>ch4</code>, because someday you may want to insert another chapter between Chapter 3 and Chapter 4. Name it after the chapter's title instead; this is also more descriptive. The only numbers in filenames should be dates and application version numbers.<br />
<br />
'''Filenames are lowercase.''' It makes URLs consistent throughout the site, and it's easier to remember the URL when case isn't an issue. The exception is documenting code: a doc on <code>nsFoo</code> should be <code>nsFoo.html</code>, not <code>nsfoo.html</code>, to match the code's casing. In no event should you have two files in the same directory that differ only in case: don't have <code>Foo</code> and <code>FOO</code>.<br />
<br />
'''Hyphenate.''' Don't use StudlyCaps to separate words. You can't use uppercase anyway. Use hyphens. Don't use underscores to separate words; underscores don't show up in underlined text.<br />
<br />
'''Don't use funny characters in file names.''' Stick to alphanumerics and hyphen. Our server is a Unix machine, and life gets somewhat more difficult if you use files with spaces, ampersands, quotes, and so on in their names. <code>this-and-that</code> is good. <code>This&That.HTM</code> is bad. You will royally screw anyone using a Macintosh (and Windows, I think) if you use colons, so don't do that.<br />
<br />
'''Avoid redundancy; don't over-qualify.''' <code>dom/domref/dom-window-ref</code> is too much—<code>dom/reference/window</code> is better.<br />
<br />
=== Location ===<br />
<br />
'''Pick (or create) the most logical location for the document.''' Get a feel for the site's organization and fit the document where it most belongs. Look at the site through it's tree structure rather than through the site navigation to get a better idea of where things go. The URI you're assigning to that file is more or less permanent, so it has to be forwards-compatible.<br />
<br />
'''Use subfolders.''' If you have a few files that belong together, or if you expect to, make a subfolder that contains all the related files.<br />
<br />
'''A file's images go in its folder.''' Don't create an "images" folder. For example, a <code>roadmap/</code> (<code>roadmap/index.html</code>) would put its diagram at <code>roadmap/diagram</code>. If the same image is used in several pages, then put it in the deepest common folder.<br />
<br />
=== Linking, Anchors, and URLs ===<br />
<br />
'''Don't point to index.html directly.''' Point to the directory rather than the <code>index.html</code> file. (Include the trailing slash.)<br />
<br />
'''Use relative links whenever practical.''' This reflects the relationship between the two documents, and the link won't break if, for instance, someone copies the documents to a test site.<br />
<br />
'''Use id="anchor-name" for intra-page anchors.''' Also, anchors should, like filenames, be lower case.<br />
<br />
'''Anchors should not be empty.''' They should enclose some relevant fragment of text. For example, to create an anchor for a section add the id attribute to the enclosing section or div tag (if there is one) or to the heading tag itself (if there isn't). If this is done right, styling the anchoring element can be a meaningful and useful styling.<br />
<br />
== Page Code ==<br />
=== Code Format ===<br />
<br />
'''Use UTF-8.''' Use HTML named entities or Unicode numerical codes for escapes, like &amp;#8212; or &amp;mdash; for an em dash. Do not use references to Windows CP1252 code points even if they appear to work. That is, do not use &#151; for em dash (or any other references to the 128…159 range).<br />
<br />
'''Use short lines.''' Some HTML editors like to produce documents that only insert line breaks in the HTML source at the ends of paragraphs. Don't do that. Use editors that give the HTML source sensibly short lines. If every paragraph is one long line, then diff is mostly useless (since diff is line-oriented.) Also there's always the chance that some random Unix utility is going to blow a buffer. Don't go there.<br />
<br />
'''Lowercase is preferred''' (but not required) for HTML tags and attributes.<br />
<br />
'''Don't use &amp;nbsp; unnecessarily.''' The fact of life of HTML is that sentences don't end in two spaces. Accept it. Don't try to work around it by using &nbsp;. Corollary: use <code>&lt;pre&gt; if you need to; not <code>&lt;tt&gt;</code> and a bucketful of non-breaking spaces. <br />
<br />
=== Validation ===<br />
<br />
'''All new pages should validate as HTML 4.01 Strict or HTML5''' using the [http://validator.w3.org/ W3C Validator]. This ensures that the page doesn't have syntax errors, that it can be processed by all sorts of more obscure browsers, and that it doesn't use the presentational markup deprecated in HTML 4.0. Also, we're making one of the most standards-compliant browsers around. It would be bad show to have an incompliant website.<br />
<br />
=== Markup ===<br />
<br />
'''''Use semantic markup.''''' Semantic markup explains why something should be styled rather than how it should be styled. This lets different style sheets and different browsers present the same idea differently and still be correct. <code>&lt;p&gt;</code>, <code>&lt;code&gt;</code>, and <code>&lt;em&gt;</code> are semantic elements. <code>&lt;b&gt;</code> and <code>&lt;i&gt;</code> are not. Stylistic information belongs in the style sheet, not the markup. Nearly everything else is corollary. So:<br />
<br />
*Presentational markup is ''discouraged'' on mozilla.org even if it's allowed in HTML 4.01 Strict.<br />
*Use <code>&lt;p&gt;</code> to ''enclose'' paragraphs, not <code>&lt;br&gt;</code> or <code>&lt;p&gt;</code> to separate them.<br />
*Use [http://www.w3.org/TR/html4/struct/global.html#h-7.5.5 Headings] for headings, not an arbitrary combination of <code>&lt;b&gt;</code>, <code>&lt;big&gt;</code>, <code>&lt;hr&gt;</code>, and/or CSS.<br />
*Don't use tables for layout. Tables are for tabular data. Text columns are not tabular data.<br />
<br />
Recommended Reading: [http://www.oasis-open.org/docbook/documentation/reference/html/ch01.html#AEN367 Structured and Semantic Markup] from <cite>DocBook: The Definitive Guide</cite> (in Chapter 1) It's about 5 pages in the print version (4 pages printed), and worth the few minutes it takes to read.<br />
<br />
=== Adding Style ===<br />
<br />
Stylistic information is centralized into several site-wide style sheets. This way, the site has a coherent look and feel and the formatting conventions are consistent. Reuse the site's markup conventions. If there's a commonly-used construct that's missing from the global style sheets, file a bug to add it there instead of working around the deficiency in your corner of the site.<br />
<br />
However, the site style sheets can't handle everything, so some pages may need to incorporate additional rules for local use or to handle specific page layouts. If that's the case with you:<br />
<br />
'''Don't depend on any particular presentation for an element or class.''' Our content outlasts our site designs. You can depend on a set of sensible style rules, but don't depend on, e.g. all filenames being rendered in a monospaced font. A style might decide to make them italic serif.<br />
<br />
'''No inline styles.''' The style attribute is banned from mozilla.org pages with two exceptions: float and clear. Use semantic markup and either <link>ed style sheets or <style>.<br />
<br />
'''Share common styles.''' If the same rules are used on more than one page, but not globally, put them in a separate style sheet file placed in the deepest folder common to those files.<br />
<br />
'''Avoid creating presentational classes.''' class="center" is no better than align="center".<br />
<br />
'''Do not set font-family.''' The font is handled by site style sheets. Other font properties are allowed, but don't change the font for the entire page (e.g. don't set <code>font-size: small</code> on <code>&lt;body&gtl;</code>).<br />
<br />
'''Avoid setting any colors''' on individual pages. If for some reason you need to set specific colors:<br />
<br />
*Make sure you reset all the element's children as well. <br />
*Make color rules <code>!important</code>.<br />
*Never set a text color without also setting a background color, and vice versa.<br />
*Use the <code>background</code> shorthand property, not <code>background-color</code> or <code>background-image</code>.<br />
*If you're using a background image, also set a matching background color. <br />
<br />
.class {<br />
color: black !important;<br />
background: gray url(slate.gif) !important;<br />
}<br />
.class * {<br />
color: inherit !important;<br />
background: transparent !important;<br />
}<br />
<br />
'''Pages must be legible in NS4+, MSIE6+, and Mozilla, with or without CSS or JS.''' We're trying to upgrade the Web here. Don't block the dark forgotten reaches who haven't seen the light of the latest shiny, or have access problems and are jumping through hoops to reach us. It doesn't have to be pretty, but it has to work.<br />
<br />
'''Make sure multiple window sizes work.''' Resize the window, both narrow and wide. (No, ''really'' narrow: 900 pixels is not narrow, it's normal.) Another common mistake made by people using HTML editors is the presence of random <code>&lt;br&gt;</code> tags at the ends of lines.<br />
<br />
== Content ==<br />
<br />
=== Writing Form ===<br />
<br />
'''Avoid all caps.''' If the uppercase is used for style (e.g. for emphasis), let the style sheet handle it. If you are talking about <code>SOME_RANDOM_C_TOKEN</code>, make sure you mark it with <code>&lt;code&gt;</code>.<br />
<br />
'''mozilla.org''' is spelled in lowercase. The name of the application is Mozilla. It is a proper noun, and is therefore capitalized. The name of the organization is mozilla.org. It is a host name, and therefore, is lowercase. Even if it is at the beginning of a sentence, it should always be lowercase. If it bothers you to begin a sentence with a lowercase word, rephrase the sentence. (It's not hard.) Never type Mozilla.org.<br />
<br />
'''Use proper capitalization for titles and headings.''' This keeps capitalization consistent throughout mozilla.org. Also, although CSS can manipulate case, it can't do proper capitalization—so that needs to be written in.<br />
<br />
'''Use a spell checker.''' Say no more.<br />
<br />
=== Writing Style ===<br />
<br />
'''Eschew marketing obfuscation.''' These are technical documents, folks. One of the things that people seem to like best about the existing content on mozilla.org is that it is written by people, for people, without bluster or self-promotion.<br />
<br />
When describing something, don't tell people how great it is. Don't tell them how useful it is. Tell them what it does. Tell them what it's for.<br />
<br />
Don't use buzzwords. Instead, say what you mean. Never use a long word where a short one would do. If it's possible to cut a word out, cut it out.<br />
<br />
Read George Orwell's Politics and the English Language. Read it again. Have it tattooed on the inside of your eyelids.<br />
<br />
'''Separate technical and religious topics.''' It is ok to publish documents which advocate potentially controversial ideas or approaches. However, it is generally better if such advocacy not be in the same document as technical information. For example, a document explaining what you have to do in order to successfully use C++ is a good thing; and a document arguing that you should not use C++ is also a good thing; however, they should not be the same document, because the controversial part might cause the readers to disregard the factual, non-controversial part, and miss out on important information.<br />
<br />
'''Speak for yourself.''' You don't speak for mozilla.org. Don't make promises about what mozilla.org will or will not do in the future. Hedge your bets with words like might or (sometimes) probably.<br />
<br />
Be careful with the word we. It would be bad if you made some assertion about what mozilla.org (as a whole) believes or desires or likes, only to find that there are others in the organization who disagree.<br />
<br />
Also, if you are employed to work on Mozilla, keep in mind that you likely wear two hats: your company hat, where you are concerned with shipping branded software; and your mozilla.org hat, where you are concerned with shipping source code on which other developers can base their own works. These two jobs are not the same, and you should be careful not to conflate the two.<br />
<br />
'''Don't play lawyer.''' Sometimes you may find yourself writing something about what is or is not allowed by the terms of the NPL, MPL, or some other license. Be very, very careful. It's probably best to say nothing at all, but if you must, you should defer to the authority of the license itself. Unless you actually are a lawyer, you're not qualified to interpret what it says, and you don't want to inadvertently say something that might get either mozilla.org or your employer into trouble.</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Gecko:FullScreenAPI&diff=310985Gecko:FullScreenAPI2011-05-20T23:25:26Z<p>Fantasai: /* Proposed Specification */</p>
<hr />
<div>== Requirements ==<br />
<br />
* Scripts should be able to initiate and terminate full-screen<br />
** Allows custom, in-page, discoverable UI to active full-screen<br />
* Arbitrary Web content should be visible full-screen<br />
** &lt;video&gt;, &lt;canvas&gt;, multicolumn text, etc<br />
** Required for scripted video controls<br />
* Entering and exiting full-screen must trigger events<br />
** To allow scripted changes to content, e.g. resizing of canvas content<br />
* Scripts should be able to opt in to having alphanumeric keyboard input disabled during full-screen<br />
** Enables less restrictive anti-spoofing measures<br />
* Actual full-screen transitions must be allowed to be asynchronous and entirely at the discretion of the UA<br />
** To enable passive notification/confirmation UI<br />
** To enable a wide range of security measures to prevent spoofing or other abuse<br />
<br />
* Making a single element full-screen should be as simple as possible<br />
<br />
* Content in IFRAMEs should be able go full-screen<br />
** To enable "widgets" such as embedded videos to offer full-screen UI<br />
<br />
== Proposed Specification ==<br />
<br />
A Document can be in the "full-screen state". What exactly this means is up to the UA, but typically it means that the Document covers most or all of the screen and some or all of the normal UA UI is not visible.<br />
<br />
It is possible for non-toplevel browsing contexts to have their Document in the full-screen state. The parent browsing context of a browsing context with its Document in the full-screen state must also have its Document in the full-screen state.<br />
<br />
The user agent may transition a Document into or out of the full-screen state at any time, whether or not script has requested it. User agents are encouraged to provide standard UI to exit the full-screen state, for example if the user presses the Escape key.<br />
<br />
Toplevel browsing contexts can be in a "keys disabled" state. In this state,<br />
the user agent must suppress all keyup, keydown and keypress events whose keyCode is not in one of the following ranges:<br />
* DOM_VK_CANCEL to DOM_VK_CAPS_LOCK, inclusive<br />
* DOM_VK_SPACE to DOM_VK_DELETE, inclusive<br />
* DOM_VK_SEMICOLON to DOM_VK_EQUALS, inclusive<br />
* DOM_VK_MULTIPLY to DOM_VK_META, inclusive<br />
Such events are not dispatched to any nodes in any document of the toplevel browsing context or descendant browsing contexts. This includes suppression of any internal key event processing that would insert text into form controls or editable content. The user agent might respond to such events by leaving full-screen mode.<br />
<br />
Each document has an optional "current full-screen element".<br />
<br />
New method of Document:<br />
<br />
* void cancelFullScreen()<br />
<br />
Requests that the UA exit full-screen mode. The UA is not required to honor this, for example the UA might require that only a Document that last triggered full-screen can cancel it.<br />
<br />
The current full-screen element for the document is cleared.<br />
<br />
New methods of Element:<br />
<br />
* void requestFullScreenWithKeys()<br />
<br />
The current full-screen element for the document is set to this element.<br />
<br />
Typically the user agent would react by transitioning the Document to the full-screen state, or by presenting asynchronous confirmation UI and transitioning to the full-screen state if/when the user responds affirmatively. However, the user agent is not required to do anything at all in response to requestFullScreen. The user agent's behavior is allowed to vary depending on whether requestFullScreen is called during a user event (e.g. a mouse click handler).<br />
<br />
* void requestFullScreen()<br />
<br />
As requestFullScreenWithKeys, but hints to the UA that while in full-screen state, the toplevel browsing context for this Document should have keys disabled. While keys are disabled, there may be a reduced risk of spoofing attacks inducing the user to input inappropriate data, and the UA may choose to relax restrictions on entering full-screen state with keys disabled.<br />
<br />
New DOM attribute of Document:<br />
<br />
* readonly attribute boolean fullScreen<br />
<br />
Returns true while the document is in the full-screen state.<br />
<br />
* readonly attribute boolean fullScreenKeyboardInputAllowed<br />
<br />
Returns true while the window's toplevel browsing context is full-screen and not in a "keys disabled" state.<br />
<br />
New content attribute of the <iframe> element:<br />
<br />
* allowfullscreen<br />
<br />
This is a boolean attribute. When this attribute is not set, UAs must ignore full-screen requests in the iframe or its descendant frames.<br />
<br />
New events:<br />
<br />
* fullscreenchange<br />
<br />
When a Document enters or leaves the full-screen state, the user agent must queue a task to dispatch this event. When the event is dispatched, if the document's current full-screen element is an element in the document, then the event target is that element, otherwise the event target is the document. The event bubbles and is not cancellable.<br />
<br />
The 'onfullscreenchange' event handling attribute is supported on HTML elements.<br />
<br />
New CSS psuedoclass:<br />
<br />
* :full-screen<br />
<br />
While a Document is in the full-screen state, and the document's current full-screen element is an element in the document, the 'full-screen' pseudoclass applies to that element. Also, an <iframe>, <object> or <embed> element whose child browsing context's Document is in the full-screen state has the 'full-screen' pseudoclass applied.<br />
<br />
New CSS media query selector:<br />
<br />
* <code>full-screen</code><br />
<br />
that accepts two states:<br />
<br />
* <code>on</code><br />
* <code>off</code><br />
<br />
Note from fantasai: http://www.w3.org/TR/view-mode/ covers this already<br />
<br />
While a Document is in the full-screen state, the full-screen media type is active for the document.<br />
<br />
Suggested UA stylesheet rules:<br />
<br />
/* A full-screen element that is not the root element should be stretched<br />
to cover the viewport. */<br />
:full-screen:not(:root) {<br />
position:fixed;<br />
top:0;<br />
left:0;<br />
right:0;<br />
bottom:0;<br />
z-index:2147483647;<br />
background:black;<br />
}<br />
/* In full-screen mode, if the root element itself is not full-screen then<br />
we should hide the viewport scrollbar. */<br />
@media all and (full-screen:on) {<br />
:root:not(:full-screen) {<br />
overflow:hidden;<br />
}<br />
}<br />
<br />
Note that it is possible for a document to position content over an element with the :full-screen pseudo-class, for example if the :full-screen element is in a container with z-index not 'auto'.<br />
<br />
== Suggested UA Policy ==<br />
<br />
The specification intentionally gives UAs great freedom in policy, because no one policy can fit all users, devices, and user interface designs. However, here is a policy that should be acceptable for conventional desktop browsers.<br />
<br />
* requestFullScreen while the window is already in the full-screen state is approved.<br />
* Otherwise, requestFullScreen outside a user action (e.g. a non-synthesized input event handler) is denied.<br />
* Otherwise, requestFullScreen without the ALLOW_KEYBOARD_INPUT flag is approved.<br />
* Otherwise, passive confirmation UI is presented and requestFullScreen is approved if and when the user approves it.<br />
<br />
== Implications ==<br />
<br />
There is no requirement to exit full-screen state when a browsing context is navigated to a new page.<br />
<br />
There is no requirement to exit full-screen state if the current full-screen element shifts to another element, or ceases to be an element in the document (e.g. because requestFullScreen was called again in the document or in some descendant document, or because the element is removed).<br />
<br />
Nothing in this specification depends on whether the current full-screen element is visible (e.g. whether it has "display:none").<br />
<br />
Nothing in this specification affects or depends on focus.<br />
<br />
== Examples ==<br />
<br />
1. Make a video element display full-screen when clicked and leave full-screen when it ends.<br />
<br />
&lt;video src="pelican.webm" autoplay<br />
onclick="event.target.requestFullScreen()"<br />
onended="document.cancelFullScreen()"&gt;<br />
&lt;/video&gt;<br />
<br />
2. Make a canvas element display full-screen in response to user input. Resize the canvas to the appropriate resolution while it's full-screen.<br />
<br />
&lt;script&gt;<br />
function redrawCanvas(c) { ... }<br />
function resizeCanvas() {<br />
var c = document.getElementById("c");<br />
var rect = c.getBoundingClientRect();<br />
c.width = rect.width;<br />
c.height = rect.height;<br />
redrawCanvas(c);<br />
}<br />
&lt;/script&gt;<br />
&lt;canvas id="c" onfullscreenchange="resizeCanvas()"&gt;&lt;/canvas&gt;<br />
&lt;button onclick="document.getElementById('c').requestFullScreen()"&gt;<br />
Go Fullscreen!<br />
&lt;/button&gt;<br />
<br />
3. Hide advertisements while the window is full-screen.<br />
<br />
@media all and (full-screen:on) {<br />
.advertisement { display:none; }<br />
}<br />
== Security ==<br />
Date of discussion: 2011.04.11<br />
<br />
Security Concerns:<br />
* Ability of website to enter fullscreen and pre-empt keyboard focus<br />
* User interaction currently not required for entering full screen mode<br />
* Fullscreen could be used as an attack vector<br />
Responses:<br />
* There is a mode called without keys that does not take keyboard input<br />
* Focus is released on tab change or window change<br />
Possible Remediations:<br />
* ESC key should be used to exit, similar to other well known apps users are familiar with<br />
* A user preference should be available for users to say allow full-screen or dis-allow full screen for a given URL domain (Ie. Popup or geolocation preferences)<br />
* Possible use of some indicator to show a user they are in full-screen mode<br />
* Possible use of permission manager<br />
* Plug-ins should be disabled when in full-screen mode<br />
To-Do<br />
* Re-review as spec firms up and code begins to land<br />
<br />
=== Jesse's concerns ===<br />
Added 2011-04-21<br />
<br />
I'm worried about having a full screen mode that does not require user permission. In particular, I have three concerns:<br />
* It allows spoofing for the purpose of '''tricking the user into giving away information through mouse input'''.<br />
** Spoof your bank, asking you to enter your password or PIN with an on-screen keypad. This is actually a plausible request from a bank! In an attempt to defeat simple keyloggers, some banks require the use of an on-screen keypad. (Examples: [https://www.westpac.com.au/ Westpac], [http://boingboing.net/2005/02/12/citibank_uk_banking_.html others])<br />
** On a touch-screen device, what you think is your on-screen keyboard could actually be part of the web page.<br />
** (This could be mitigated by replacing "full screen without keys" with "full screen with video-like controls only": any user interaction makes a scrubber and volume controls appear.)<br />
* It allows spoofing for the purpose of '''tricking the user to take an action later or outside of the browser'''.<br />
** Spoof your bank, saying you "Please call us to discuss possible fraud on your account". Supply an attacker-controlled phone number.<br />
** Spoof https://www.mozilla.org/, asking you to "download the new version of Firefox".<br />
** Spoof https://twitter.com/, showing tweets indicating your company has been bought by AOL.<br />
** Spoof https://www.facebook.com/, showing fake evidence that your wife is cheating on you.<br />
** Spoof the [http://support.apple.com/kb/ht1392 You need to restart your computer] screen. Are you going to think of pressing Esc, or are you going to power-cycle?<br />
** More generally, this makes it more difficult to explain how to find out which site you're on. Instead of "look at the address bar…", instructions must start with "press Esc, then look at the address bar…".<br />
* Entering full-screen mode '''reveals the screen size''', which is a privacy/fingerprinting hazard (assuming we fix {{bug|418986}}).<br />
<br />
I should be absolutely sure that after pressing Esc, I'm not in full-screen mode.<br />
* When I'm in full-screen mode, pressing Esc should leave, even if the site uses preventDefault.<br />
* When I'm not in full-screen mode, pressing Esc (or Cmd+W, etc) should not as a "user-initiated event that allows popups and full-screening"<br />
<br />
I should be sure that after full-screening YouTube, another site cannot navigate me away from YouTube and remain in full-screen mode. That means changing "There is no requirement to exit full-screen state when a browsing context is navigated to a new page."<br />
<br />
'''I'd prefer just putting a full-screen button on our toolbar.''' Let users choose when to full-screen the page themselves. If the user chooses to hide the button, web pages could be allowed to make it appear again temporarily.<br />
<br />
Advantages:<br />
* No need for a auto-allow-but-limited-input mode, with all the security and usability problems it brings.<br />
* Fewer clicks. One click (on the toolbar button) instead of two (one in the page, one to allow).<br />
* We don't have to worry about timing or confusion attacks against the permission UI.<br />
* Consistent UI across the web.<br />
<br />
Disadvantages:<br />
* Harder for youtube-in-iframe to become full-screen.<br />
* Uses toolbar space.<br />
<br />
== Issues ==<br />
<br />
=== naming one word or two ===<br />
'''fullscreen''' vs '''full screen'''<br />
<br />
* '''fullscreen''' <br />
** text of this page repeatedly uses "fullscreen"<br />
** Wikipedia prefers "[https://secure.wikimedia.org/wikipedia/en/wiki/Fullscreen fullscreen]" and redirects "[https://secure.wikimedia.org/wikipedia/en/wiki/Full_screen full screen]" to that page.<br />
<br />
* '''full screen'''<br />
** title of this page implies "full screen" from the camelcase: ([[Gecko:FullScreenAPI|FullScreenAPI]])<br />
** the Firefox 4 "View" menu item "Full Screen" (shift-command-F)<br />
<br />
''roc: Elika and I resolved to use 'full-screen' everywhere.''<br />
<br />
=== avoiding ancestor reflow ===<br />
Currently, the suggested UA stylesheet rules for a non-root fullscreen element take it out of the flow and make it position fixed, which has the side-effect of causing its ancestors to reflow, which is unnecessary, and thus an undesirable performance hit.<br />
<br />
Instead, we should consider simply defining the fullscreened element as creating a new view with itself as the root box of a CSS presentation, with its own opaque CSS canvas (as defined in CSS), thereby avoiding the reflow problem.<br />
<br />
The underlying background of this new opaque CSS canvas comes from the fullscreened element, just as the underlying background of a window comes from the root element of the document in that window.<br />
<br />
''roc: I don't want to do it this way. Creating additional views is very difficult to fit into the architecture of Gecko and other engines. The existing way seems fine in practice. Reflowing the document is not going to be a significant performance issue.''<br />
<br />
=== avoiding drawing anything else ===<br />
Also, the suggested UA stylesheet rules use z-index to put the fullscreened element above everything else. Instead we may want to specify that when something is fullscreened, that we don't bother rendering any other windows/tabs, nor the parent document.<br />
<br />
''roc: Again this is more invasive to the engine than necessary. The z-index approach should work fine and is simple, without requiring any special engine support.''</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Tantek-Mozilla-Projects&diff=305576Tantek-Mozilla-Projects2011-05-04T19:01:36Z<p>Fantasai: /* remaining tasks */ note ime-mode as an issue</p>
<hr />
<div>Hi, I'm [[User:Tantek|Tantek Çelik]], and you've found my list of projects that I'm working on with Mozilla.<br />
<br />
I'm currently (as of 2010-146) a Mozilla contractor working with Chris Blizzard and the web [[standards]] team, focused on specification work, especially around web applications user interfaces and social/identity open web technologies. I participate in standards related [[events]] for both official organizations like W3C, and grass-roots efforts like microformats and ActivityStreams. If you have feedback for these groups, let me know!<br />
<br />
Specifications, efforts and summary status:<br />
* CSS<br />
** CSSWG 2011-2013 charter: http://wiki.csswg.org/planning#charter-2011<br />
** [[Tantek-Mozilla-projects#CSS3_UI|CSS3 UI]]: editing CR toward producing a new LCWD.<br />
** [[Tantek-Mozilla-projects#Full_Screen|Full Screen]] - needs a first draft specification. Start with [[Gecko:FullScreenAPI]].<br />
** [[Tantek-Mozilla-projects#CSS_Style_Attributes|CSS Style Attributes]]: Achieved Candidate Recommendation (CR). Next action: test suite to help exit CR.<br />
** [[Tantek-Mozilla-projects#CSS3_Color|CSS3 Color]]: Achieved Proposed Recommendation (PR). Waiting for: CSS 2.1 to reach PR, so that CSS3 Color can go REC.<br />
** [[Tantek-Mozilla-projects#UI_Layout|CSS UI Layout: Flexbox and Grid]]: Updated Flexbox public WD imminent. Grid needs iteration to simplify simple cases.<br />
** [[Tantek-Mozilla-projects#CSS3_Element|CSS3 Element]]: decide which draft to get it into (separate draft, Values and Units) and update draft accordingly.<br />
** [[Tantek-Mozilla-projects#CSS4_UI|CSS4 UI]]: collecting ideas, features, proposals towards writing a FPWD.<br />
** [[Tantek-Mozilla-projects#CSS4_Color|CSS4 Color]]: collecting ideas, features, proposals towards writing a FPWD.<br />
* [[Tantek-Mozilla-projects#HTML5_spec_improvements|HTML5]]: <br />
** follow-up on rejected/accepted spec improvement suggestions, figuring out next-steps for anything rejected<br />
** figure auto-close p issue. awaiting feedback from HTML5 Superfriends... then blog or email public-html about it.<br />
* [[Tantek-Mozilla-projects#DOM_API_vendor_prefixing|DOM API vendor prefixing]]: discussing internally at Mozilla to build consensus, set a good example.<br />
* [[vCard4]]: waiting-for responses to feedback on draft 15 to vcarddav group, updated draft (16?) with at least some of my requested changes being accepted.<br />
<br />
Unfiled:<br />
* Review http://dev.w3.org/csswg/css-module/Overview.src.html<br />
<br />
See below for more details on each.<br />
<br />
== Web Apps ==<br />
=== UI Styling ===<br />
At a high level there are two general clusters of use cases that web pages/apps want/need to solve in terms of user interface fidelity.<br />
<br />
'''1. Beautiful Built-in Tweakable Controls.''' Pages that have some interactivity where the designer wants to use the built-in set of semantic user interface controls/inputs as long as they can just "tweak" them to match their web page/site design, e.g. color, background, typography. As long as the look and feel of built-in controls is beautiful enough both by default and with minor tweaks, then the hypothesis is that web designers will be happy/content to use built-in controls rather than go the extra mile to re-build custom controls with divs and javascript etc.<br />
<br />
Some data for this hypothesis: default iPhone/iPad controls are pretty enough that most developers are more than happy to use them - the default controls make their apps look beautiful, polished, without much work/tweaking (modulo layout/sizing etc.) If we can achieve that same experience with built-in controls, the theory is that most web designers will be happy to stick with built-in controls + CSS.<br />
<br />
'''2. Rich native-app-like experiences.''' Games. Media interfaces like WinAmp. There are always going to be some user interfaces where the developer wants nearly total control of the look and feel. Just take a look at typical Flash or Flex app UIs (note: some of those are egregiously inconsistent with the underlying OS platform just for the sake of being different - hard to avoid that but we can discourage it by making the cluster 1 solution easier and more accessible). In this case I'd like to see us figure out how to build hybrid controls that:<br />
<br />
a) Are built with the closest semantic built-in control for any particular custom control, <em>and</em><br />
<br />
b) Use a &lt;canvas&gt; for drawing custom appearance, with DOM event handlers drawing control-specific state in the canvas, <em>and</em><br />
<br />
c) Have text-based fall-back in the canvas.<br />
<br />
Example markup (event attributes/handlers omitted for simplicity)<br />
<br />
<pre>&lt;button&gt;&lt;canvas&gt; Play &lt;/canvas&gt;&lt;/button&gt;</pre><br />
<br />
(Now we just need a way to do that with text inputs too.)<br />
<br />
The goal in this second scenario is to enable building rich native-app-like user interfaces where the path of least resistance to building it uses building blocks that in themselves enable accessibility. I think this is both possible, and is a necessary course of action to avoid having to do "bolt-on" accessibility later.<br />
<br />
<br />
For now, the sections below focus on addressing/solving the first cluster of use cases first.<br />
<br />
The theory is that by addressing that first that it will become more obvious which specific real-world rich interfaces fall into the second cluster, and therefore we can design for that second cluster based on those specific interfaces.<br />
<br />
==== Styling HTML5 UI elements ====<br />
We need to define how Forms and other UI elements can be styled, and to synchronize our work with the W3C.<br />
<br />
Working with Mounir Lamouri on this: [[User:Mounir.lamouri/HTML5_Forms]]<br />
<br />
Each [[HTML5]] UI element must be complete to the following criteria:<br />
<br />
1. It must include pleasant and working UI, where appropriate.<br />
<br />
This is a big design challenge. Take a look at what Opera has done for example (in terms of challenges). Here is a simple test page which shows default renderings - compare in various browsers and try interacting with the new widgets especially in Opera:<br />
<br />
http://tantek.com/new-inputs.html<br />
<br />
See [[HTML5/input]] for more &lt;input&gt; element tests.<br />
<br />
* Need more sample/test/wiki pages for other HTML5 UI elements.<br />
<br />
2. You must be able to use CSS to style the element, especially the UI that we generate. This includes any pre-defined pseudo-selectors (invalid, required, icon, etc.)<br />
<br />
Agreed, this is an absolute requirement.<br />
<br />
Whenever there is ''any'' custom appearance of a form control, e.g. based on the new types, designers ''must'' be able to restyle them to fit in with their design. This means at a minimum:<br />
* ability to select specific "pieces" of any compound/composite form control for styling<br />
** feeds into requirements for CSS pseudo-elements<br />
** consider existing [http://www.w3.org/TR/css3-ui/#pseudo-elements CSS3-UI pseudo-elements]<br />
*** ::value can be used for selecting/styling placeholder text (see [https://bugzilla.mozilla.org/show_bug.cgi?id=457801#c25 bug 457801 comment 25])<br />
*** ::choices <br />
*** ::repeat-item <br />
*** ::repeat-index<br />
** consider additional pseudo-elements based on vendor prefixed pseudos<br />
*** Safari 5 supports pseudo-elements for restyling overflow scrollbars<br />
**** ::webkit-scrollbar-thumb<br />
**** ::webkit-scrollbar-track<br />
**** ::webkit-scrollbar<br />
* ability to select specific "states" of any form control (may require ability to select states of specific pieces as well - that will be a challenge though as pseudo-elements themselves cannot have pseudo-classes in CSS)<br />
** existing [http://www.w3.org/TR/css3-selectors/#UIstates Selectors UI pseudo-classes], and some notes on [http://www.w3.org/TR/html5/interactive-elements.html#pseudo-classes how HTML5 DOM property states trigger these pseudo-classes]<br />
*** :hover :active - based on mouse/pointer interactions. the challenge here is to find alternatives for touch based interfaces.<br />
*** :focus - an element which is currently accepting keyboard, pointer, or other input device events.<br />
*** :enabled and :disabled - based on the state of the "disabled" property on the element.<br />
*** :checked - based on the "checked" property on input types "radio" and "checkbox", and also on the "selected" property on option element.<br />
*** :indeterminate - based on the "indeterminate" property of the input types "radio" and "checkbox".<br />
*** :default - [http://www.w3.org/TR/html5/interactive-elements.html#selector-default default buttons or submit buttons]<br />
*** :valid and :invalid - input elements that are candidates for constraint validation and either do or don't (respectively) satisfy their constraints.<br />
*** :in-range and :out-of-range - input elements that are candidates for constraint validation and that are neither under nor overflowing (for :in-range) or either under/overflowing (for :out-of-range).<br />
*** :required and :optional - [http://www.w3.org/TR/html5/interactive-elements.html#selector-required see HTML5 description of being required / required attribute]<br />
*** :read-only and :read-write - [http://www.w3.org/TR/html5/interactive-elements.html#selector-read-only see HTML5 description of read-only vs read-write elements].<br />
** additional pseudo-selectors as needed for states/portions included in HTML5 forms elements features<br />
*** "placeholder" attribute - needs a new :-moz-placeholder pseudo-class ([https://bugzilla.mozilla.org/show_bug.cgi?id=457801 bug 457801])<br />
**** :placeholder pseudo-class needs to be proposed for CSS3.1 UI/Selectors.<br />
* typography<br />
** font properties<br />
** text properties<br />
** color<br />
* box properties<br />
** width<br />
** height<br />
** padding<br />
** border<br />
** margin<br />
** background<br />
** box-shadow<br />
<br />
<br />
3. If there's a constraint API the API must be complete.<br />
<br />
4. It should be [[Accessibility/HTML5_Forms|fully accessible]].<br />
<br />
==== Possible new HTML5 UI elements ====<br />
The new user interface elements in HTML5 cover quite a bit of Web Apps UI scenarios. There are both requests based on specific user/application scenarios, and there is also the full set of user interface objects represented by the values of the CSS3 UI 'appearance' property<br />
===== specific new elements =====<br />
* <code>&lt;menubar&gt;</code><br />
* pull-down-menu<br />
* context-menu<br />
* <code>&lt;input type="year"&gt;</code> - based on <code>&lt;time&gt;</code> element use case research<br />
* <code>&lt;input type="month-day"&gt;</code> - based on <code>&lt;time&gt;</code> element use case research<br />
<br />
===== CSS3 UI appearance values =====<br />
From [http://www.w3.org/TR/css3-ui/#appearance-val CSS3 UI 5.1. Appearance values]:<br />
<br />
Needs:<br />
* tab - a button that looks like the browser's tabbed windows tabs.<br />
* menubar - a menu of menus, typically arranged linearly, in a horizontal bar. <br />
* pull-down-menu - a menu where the name of the menu is displayed and the options remain hidden until the user activates the menu. When the user releases or deactivates the menu, the options are hidden again.<br />
* radio-group - a menu where the options are displayed as radio-buttons.<br />
* checkbox-group - a menu where the options are displayed as checkboxes. <br />
* outline-tree - a menu where the options can be shown or hidden with small widgets, often represented by a small triangle or plus and minus signs. might be possible to build one using <code>&lt;details&gt;</code> and <code>&lt;summary&gt;</code>.<br />
* combo-box - a field which is accompanied by a menu of preset values that can be used to quickly enter common or typical values. <br />
* signature - a field for entering a signature. <br />
<br />
Full list with equivalents:<br />
* icon - handled by 'icon' property and HTML5 Drag &amp; Drop<br />
* window - mostly handled outside of elements, except perhaps 'tooltip' which could be purely presentational<br />
* button - by default a push-button<br />
** push-button - <code>&lt;input type=button&gt;<code> and <code>&lt;button&gt;</code><br />
** hyperlink - <code>&lt;a href&gt;</code><br />
** radio-button - <code>&lt;input type="radio"&gt;</code><br />
** checkbox - <code>&lt;input type="checkbox"&gt;</code><br />
** menu-item - <code>&lt;option&gt;</code> and <code>&lt;optgroup&gt;</code><br />
** tab - no HTML5 equivalent<br />
* menu - by default a pop-up-menu<br />
** menubar - no HTML5 equivalent<br />
** pull-down-menu - no HTML5 equivalent<br />
** pop-up-menu - <code>&lt;select&gt;</code><br />
** list-menu - <code>&lt;select size=n</code> (where n>1)<br />
** radio-group - no HTML5 equivalent<br />
** checkbox-group - no HTML5 equivalent<br />
** outline-tree - no complete HTML5 equivalent but <code>&lt;details&gt;</code> and <code>&lt;summary&gt;</code> may help.<br />
** range - <code>&lt;input type="range"&gt;</code><br />
* field - <code>&lt;input type="text"&gt;</code> and <code>&lt;textarea&gt;</code><br />
** combo-box - no HTML5 equivalent<br />
** signature - no HTML5 equivalent<br />
** password - <code>&lt;input type="password"&gt;</code><br />
<br />
==== CSS Style Attributes ====<br />
;latest published draft (CR)<br />
:http://www.w3.org/TR/css-style-attr/<br />
;latest development / in progress draft<br />
:http://dev.w3.org/csswg/css-style-attr/<br />
;spec source (for editing)<br />
:http://dev.w3.org/csswg/css-style-attr/Overview.src.html<br />
;test suite<br />
:TBD<br />
;implementation reports of the test suite<br />
:TBD<br />
;issues list for the current draft<br />
:http://wiki.csswg.org/spec/css-style-attr<br />
<br />
===== remaining tasks =====<br />
* test suite <br />
** expecting to work with Ted O'Connor of Apple on this<br />
<br />
===== waiting for =====<br />
* Ted O'Connor answer whether he can help with test suite / implementation reports.<br />
** emailed 2011-080<br />
* Hixie to update reference to CSS Style Attributes draft in [http://www.whatwg.org/specs/web-apps/current-work/multipage/references.html#references HTML5 References]<br />
** emailed 2011-080<br />
<br />
See also CSSWG wiki task list: http://wiki.csswg.org/spec/css-style-attr<br />
<br />
==== CSS3 UI ====<br />
;latest published draft<br />
:http://www.w3.org/TR/css3-ui/<br />
;latest development / in progress draft<br />
:http://dev.w3.org/csswg/css3-ui/<br />
;spec source (for editing)<br />
:http://dev.w3.org/csswg/css3-ui/Overview.src.html<br />
;test suite<br />
:TBD<br />
;implementation reports of the test suite<br />
:TBD<br />
;issues list for the current draft<br />
:http://wiki.csswg.org/spec/css3-ui<br />
<br />
===== remaining tasks =====<br />
Remaining tasks to get CSS3 UI to PR:<br />
<br />
* '''text-overflow'''<br />
** clarify text per emails from fantasai/RoC or consider explicitly stating as undefined (per suggestions from RoC)<br />
*** the behavior of text-overflow:ellipsis on a block with 'overflow' of 'scroll' (no good interop, ideal behavior documented, needs screenshots)<br />
**** testcase from RoC: http://lists.w3.org/Archives/Public/www-style/2011Jan/att-0669/test.html<br />
*** interaction of text-overflow:ellipsis with event handling<br />
*** behavior of text-overflow:ellipsis on lines containing replaced elements<br />
** also create an implementer FAQ on the CSS WG wiki re: text-overflow accordingly<br />
* '''resolve issues'''. resolve/apply proposals from issues list: http://wiki.csswg.org/spec/css3-ui <br />
* '''overflow-x overflow-y'''. consider incorporating '''[https://developer.mozilla.org/En/CSS/Overflow-x overflow-x]''' and '''[https://developer.mozilla.org/En/CSS/Overflow-y overflow-y]'''<br />
** pull-in the entirety of section 16 from<br />
*** http://www.w3.org/Style/Group/css3-src/css3-box/#overflow<br />
** sync (incorporated) any updates/changes in 2.1:<br />
*** http://www.w3.org/Style/Group/css2-src/visufx.html#overflow<br />
** search www-style for issues related to 'overflow-x' and 'overflow-y'<br />
*** ask Anne van Kesteren and www-style directly<br />
** check that css3-marquee implicitly deals with overflow-x and overflow-y correctly<br />
*** http://www.w3.org/TR/css3-marquee/#the-overflow-style<br />
** investigate discussion of ink overflow vs layout overflow - [[User:Fantasai|fantasai]] will get more info on this. e.g. box-shadow should never trigger scrollbars. do margins? maybe they don't trigger overflow but if there is overflow anyways (something else triggers scrollbars), then margins influence the dimensions of the scrollable area.<br />
* investigate whether ''ime-mode'' should be added?<br />
** https://developer.mozilla.org/en/CSS/ime-mode<br />
** It is implemented unprefixed<br />
<br />
* '''implementation documentation'''. document claims of existing implementations (CSSWG implementers have until 2010-09-17 to submit claims of implementation)<br />
** Webkit CSS3 UI - http://lists.w3.org/Archives/Public/public-html/2009Sep/0060.html<br />
** Opera CSS3 UI - http://lists.w3.org/Archives/Public/public-html/2009Sep/0202.html<br />
** Mozilla CSS3 UI<br />
*** [https://developer.mozilla.org/en/CSS/:default :default]<br />
*** [https://developer.mozilla.org/En/CSS/:indeterminate :indeterminate]<br />
*** [https://developer.mozilla.org/En/CSS/::selection ::-moz-selection] - needs removal of prefix.<br />
*** [https://developer.mozilla.org/en/CSS/:-moz-placeholder :-moz-placeholder]<br />
*** more UI related pseudo-classes discussed in [https://developer.mozilla.org/en/CSS_Reference#Pseudo-classes devmo CSS Reference]<br />
*** [https://developer.mozilla.org/en/CSS/-moz-appearance -moz-appearance] - needs analysis to figure out if it complies with intent of 'appearance' property<br />
*** [https://developer.mozilla.org/En/CSS/Box-sizing -moz-box-sizing] - needs unprefixing ([https://bugzilla.mozilla.org/show_bug.cgi?id=243412 bug 243412]). <br />
**** extra value 'padding-box' is implemented - consider adding it to CSS3-UI<br />
*** 'cursor' - new values<br />
**** [https://developer.mozilla.org/en/CSS/-moz-alias alias] - verify works w/o prefix.<br />
**** [https://developer.mozilla.org/en/CSS/-moz-cell cell] - verify works w/o prefix.<br />
**** [https://developer.mozilla.org/en/CSS/-moz-copy copy] - verify works w/o prefix.<br />
*** [https://developer.mozilla.org/en/CSS/outline-offset outline-offset] - <br />
** Internet Explorer 8 CSS3 UI support - ??? (expect email from johnjan @ MS)<br />
** IE5/Mac CSS3 UI support - ???<br />
<br />
* draft and publish at least a minimal coverage test suite that covers those claims<br />
<br />
* document actual implementation results<br />
<br />
* reducing feature set down to what's been implemented in more than one browser<br />
** write new CSS3 UI LCWD editors draft with only non-at-risk features based on above implementation evidence (or imminent implementation - kept at risk)<br />
** write new UI Selectors FPWD editors draft with all new UI selectors (consider limiting to those with at least one implementation, any with less than 2 implementations, mark at risk up front)<br />
* collect/address new CSS3 UI LCWD issues as they are reported<br />
** respond to all the commenters on issues with proposed resolutions (hopefully thus addressing their concerns and resolving the issues accordingly)<br />
** incrementally draft new CSS3-UI CR draft accordingly<br />
<br />
* wait for new CSS3 UI LCWD last-call period to end<br />
<br />
* write UI Selectors LCWD - with features with at least one implementation, any with less than 2 implementations, mark at risk.<br />
<br />
* edit CSS3-UI CR draft accordingly that is ready for PR<br />
<br />
* WG processes for taking it to PR<br />
<br />
Remaining related Firefox bugs/development tasks (stub/incomplete)<br />
For each of these, figure out who is the right Mozilla developer to work on this and then work with to understand what it will take to get it implemented:<br />
* cursor / border-radius interaction bug: [https://bugzilla.mozilla.org/show_bug.cgi?id=595652 595652]<br />
** if/when fixed, add that detail to spec<br />
* cursor on root element applying to viewport: [https://bugzilla.mozilla.org/show_bug.cgi?id=568450 568450] <br />
** if/when fixed, add that detail to spec<br />
* icon support: http://www.w3.org/TR/css3-ui/#element<br />
** 'icon' property<br />
** 'content:icon' value<br />
* box-sizing prefix drop: https://bugzilla.mozilla.org/show_bug.cgi?id=243412<br />
* ...<br />
<br />
Additional CSS3 UI related features in Mozilla to investigate:<br />
* [https://developer.mozilla.org/en/CSS/-moz-user-focus -moz-user-focus]<br />
<br />
==== CSS4 UI ====<br />
* write CSS4 UI FPWD with:<br />
** public requests recorded: http://wiki.csswg.org/spec/css4-ui<br />
** previous CSS3-UI features that got dropped<br />
*** stuff from CSS3 UI CR that only had one implementation (that we believe is worthy of standardizing, or at least one other implementer expresses interest on)<br />
*** stuff from and related to previous CSS3 UI drafts that's been reraised<br />
**** 'user-input'<br />
**** 'user-focus'<br />
**** 'user-modify'<br />
**** 'user-select'<br />
***** all suggested to replace 'contentEditable': [http://lists.w3.org/Archives/Public/www-style/2010Dec/0371.html www-style: Implementing contentEditable in CSS3 UI]<br />
** other CSS features that are UI related in other CSS or other W3C specs<br />
*** :placeholder pseudo-class. related: [https://bugzilla.mozilla.org/show_bug.cgi?id=457801 bug 457801]<br />
*** '''overflow-radius''' per implementation: Mozilla supports [https://developer.mozilla.org/en/CSS/-moz-outline-radius -moz-outline-radius] (no second implementation however - thus in CSS4 UI)<br />
*** CSS3 Hyperlink<br />
*** [[HTML5]] inputs/forms features that are presentation related<br />
** new features<br />
*** CSS portions of [[Gecko:FullScreenAPI]], e.g. the new pseudo-classes<br />
*** <span id="new-resize-values">new 'resize' values</span> - e.g. '''grow-vertical''', '''grow-horizontal'''<br />
**** Facebook uses some JS to add rows to text areas when you hit the end of the available space. It feels nicer than a scrollbar because you can see all of what you typed -- the height of the text area just grows and grows as you need it. It would be great to have 'resize' property values that allow the browser to auto-grow a textarea as a user enters data, e.g. 'grow-horizontal', 'grow-vertical'. 'grow-vertical' would emulate the current behavior that FB does with JS. (note from fantasai - this is the behavior you'd get with fixed min-height and auto height, so CSS can do this already if HTML doesn't get in the way)<br />
**** Update 2011-032: [http://twitter.com/LeaVerou/status/32642516146724866 @LeaVerou requested] "elastic textarea effect with pure CSS" [http://twitter.com/LeaVerou/status/32651575688175616 and follow-up]: "mostly about height, not width" which sounds like resize:grow-vertical. There's also mention of "-moz-available" (need to research that and link it up).<br />
** forward reaching properties/values to enable native-like interfaces<br />
*** 'spell-check'<br />
*** 'grammar-check'<br />
**** both suggested by: [http://lists.w3.org/Archives/Public/www-style/2010Dec/0383.html www-style: Re: Implementing contentEditable in CSS3 UI]<br />
*** more "overflow" extensions: http://wiki.csswg.org/spec/css3-overflow<br />
<br />
==== CSS3 Element ====<br />
===== write up moz-element proposal =====<br />
Firefox 4 implements background: -moz-element(#foo); to use element with id foo as the background per http://hacks.mozilla.org/2010/08/mozelement/ <br />
<br />
We're pursuing adding element(#foo) as an "at-risk" feature to the CSS3 Values and Units module.<br />
<br />
Proposal (worked with Tab Atkins)<br />
* http://lists.w3.org/Archives/Public/www-style/2010Aug/0635.html<br />
<br />
Threads:<br />
* [http://lists.w3.org/Archives/Public/www-style/2010Aug/thread.html#msg635 element() 2010-08]<br />
* [http://lists.w3.org/Archives/Public/www-style/2010Sep/thread.html#msg0 element() 2010-09]<br />
<br />
Thoughts:<br />
* CSS image() value - which Tab Atkins is already writing up<br />
* Add both to CSS3 Values and Units as at risk for taking it quickly to CR<br />
** in addition to the calc() work that David Baron is already doing in CSS3 Values and Units<br />
<br />
==== CSS4 Color ====<br />
* collect new features for CSS3.1/4 Color - color-correction<br />
** follow-up on color management properties for css3-color that were discussed at 2009 November TPAC CSS f2f (but later punted from css3-color to a future version).<br />
*** check minutes from that meeting for details on conclusions of the property (name, values etc.)<br />
*** contact Beth regarding level of implementation interest, plan to move forward with putting the color management property into a post-css3 working draft of the Color Module<br />
* write a first working draft of CSS3.1/4 Color with collected feature(s) (even if it includes just a new color management property)<br />
* find out where Hixie's tests went (was at http://test.csswg.org/source/contributors/hixie/incoming/css3-color/ ) and figure out what to do with them.<br />
<br />
=== DOM API vendor prefixing ===<br />
==== spec implementation problem statement ====<br />
Problem statement: the '''specification-implementation co-dependency problem'''.<br />
<br />
All standards in development have the challenging seemingly contradictory problems of:<br />
# '''needing some implementation to reality-check''' that the API/protocol/format "works" as intended, or is workable/usable<br />
# '''being stuck with a specific (often buggy) implementation''' once it ships because there's content/pages/apps out there that depend on it.<br />
<br />
There are three areas of the open web app platform that this has been problematic:<br />
# '''CSS'''. In the past, some properties were implemented, either as spec'd (and the spec was buggy), or in a way that made sense but incompatible with the spec (because the spec didn't make sense or was not useful to web authors), and then we got "stuck" with those implementations and were not able to update/fix the spec and the respective properties and/or values. Examples:<br />
## 'clip' property. mis-specified in CSS 2.0. implemented as presumed intended in IE4/Windows etc. but turned out to be buggy. some content started depending on it. we (CSS WG at the time) were unable to really fix it in a way that implementations could change, though [http://www.w3.org/TR/CSS21/visufx.html#clipping CSS 2.1 tries to fix clip].<br />
## 'word-wrap' property. in this case, created/proposed by Microsoft, and [http://msdn.microsoft.com/en-us/library/ms531186.aspx implemented as of IE5.5/Windows ca 2000], we are again, kind of stuck with the particular implementation. [http://www.codingforums.com/archive/index.php/t-2075.html Forum posts as of 2002 were recommending use of the literal word-wrap property]. Though since Microsoft did switch to advocating/supporting a prefixed version '-ms-word-wrap'. Note that it is also [https://developer.mozilla.org/en/CSS/word-wrap supported in Firefox 3.5 ca 2009], and it is in the latest (2007) version of the [http://www.w3.org/TR/2007/WD-css3-text-20070306/#word-wrap CSS3 Text spec which is just a working draft].<br />
### See related 'word-break' property ([http://www.w3.org/TR/2007/WD-css3-text-20070306/#word-break word-break in CSS3 Text WD] - latest, 2007), also [http://msdn.microsoft.com/en-us/library/ms531184.aspx initially (partially) implemented in Internet Explorer 5.x as word-break], and later switched to the prefixed '-ms-word-break'. [http://msdn.microsoft.com/en-us/library/cc351024%28VS.85%29.aspx More on CSS Compatibility and Internet Explorer].<br />
# '''HTML'''. Too many examples to list here. Some browsers are still stuck supporting <code>&lt;blink&gt;</code> and <code>&lt;marquee&gt;</code> (which has many odd details), nevermind the classic example of <code>&lt;table&gt;</code> layout, with tons of odd special cases and error-handling for compat, originally from Netscape's implementation, reverse-engineered by Microsoft in Internet Explorer, which has subsequently been reverse-engineered by every other browser.<br />
# '''DOM'''. In particular [http://www.w3.org/TR/2009/WD-webstorage-20091222/ Web Storage working draft] (e.g. the 'localStorage' attribute/property) was implemented in multiple browsers (IE8+, Chrome, Safari, Opera, Mozilla as of 2010 - date order unknown). By the time people discovered it was not threadsafe as specified, it was too late to change the spec to fix that problem - it would have broken too many apps/sites already written which apparently depended on it.<br />
<br />
==== existing solutions ====<br />
<br />
The only one of these areas of technology that has an explicit solution to the specification-implementation co-dependency problem is CSS, through vendor-prefixes.<br />
<br />
===== CSS vendor prefixes =====<br />
In the early 2000s the participants in the CSS working group agreed to formalize a way for implementors to build experimental implementations of new properties and values which were only in a working draft (not yet in a Candidate Recommendation) without saddling the property with implementation specific bugs that content would end up inadvertently depending on.<br />
<br />
CSS prefixing is fairly straight forward:<br />
<br />
<pre>- abbreviated_vendor_prefix - property_name</pre><br />
<br />
(spaces added for clarification of the different components)<br />
<br />
Examples include:<br />
* -moz-opacity<br />
* -o-border-radius<br />
* -webkit-border-radius<br />
* -ms-word-wrap<br />
<br />
===== CSS vendor prefixes case studies =====<br />
* '''border-radius'''. for a few years now browsers have been implementing ''vendor prefixed'' versions of the border-radius properties, web authors have been experimenting on the web, and the spec has iterated/improved based on feedback. Now we have a well-designed and road-tested 'border-radius' property in a CR spec and implementations are implementing that.<br />
* '''word-wrap vs whitespace: pre-wrap'''. interactions between new properties and new values on existing properties. See this [http://scottonwriting.net/sowBlog/archive/0000/00/00/163005.aspx example of the property vs value interaction] between the new 'word-wrap' property and the (sometimes prefixed) new 'pre-wrap' value on the 'whitespace' property. The point is to show how prefixing can actually work across different approaches to evolving CSS.<br />
<br />
===== CSS vendor prefixes successes =====<br />
Several well known web designers and developers have written at length about the successes of CSS vendor prefixes, and how they have both helped avoid problems from before, and actually improve the evolution of CSS.<br />
<br />
* [http://www.alistapart.com/articles/prefix-or-posthack/ A List Apart: Prefix or Posthack] by Eric Meyer<br />
* [http://www.webmonkey.com/2010/07/advice-from-the-css-guru-embrace-prefixes/ WIRED Webmonkey: Advice From the CSS Guru: Embrace Prefixes] by By Michael Calore<br />
* [http://www.the-haystack.com/2010/03/22/coping-with-css-prefixes/ The Haystack: Coping with CSS vendor prefixes] by Stephen Hay<br />
* [http://snook.ca/archives/html_and_css/not-supported Snook.ca: NOT SUPPORTED] by Jonathan Snook<br />
* [http://annevankesteren.nl/2010/03/css-vendor-prefix Anne van Kesteren: In defense of CSS prefixes] by Anne van Kesteren<br />
<br />
==== analysis of applicability ====<br />
Can we apply similar thinking and solutions to HTML and/or DOM?<br />
<br />
For HTML (or any markup) the thinking is no - because of the fact that an element only allows one tagname, there is no way to have content first use a vendor prefixed tagname (or tagnames from multiple vendors), and then also use a final unprefixed tagname all at the same time as part of a content evolution/transition strategy. CSS vendor prefixing works (as illustrated in the case studies) because authors ''can'' create style sheets that use multiple versions of a property (vendor prefixed and unprefixed) in one style sheet, together while evolving their content over time.<br />
<br />
For DOM, it is not only possible, but there are examples in the wild.<br />
<br />
[https://developer.mozilla.org/en/DOM/window.onmozorientation mozOrientation] is a good example of a vendor prefixed DOM interface implementation. (Note mozOrientation needs to be submitted to a W3C working group for standardization/iteration)<br />
<br />
==== simple DOM vendor prefixes proposal ====<br />
<br />
For all DOM interfaces that are:<br />
* Proprietary. No standards organization draft yet published. OR<br />
* In a W3C working draft, not yet in a Candidate Recommendation.<br />
<br />
Use vendor prefixed interfaces and values as follows:<br />
<br />
<pre>vendor_prefix _ unprefixed_name</pre><br />
<br />
E.g. in the above example of mozOrientation, we really should be using:<br />
<br />
<pre>moz_Orientation</pre><br />
<br />
This works because standard DOM APIs do not use underscores.<br />
<br />
Our goal is to establish a convention (like the above) for all such pre-CR DOM APIs that has the consensus of implementers so that we can avoid creating broken versions of APIs<br />
<br />
==== simple protocol scheme prefixes proposal ====<br />
The WebSockets specification (and iteration) provides a good example of a W3C Working Draft that has work also going on at the IETF (perhaps primarily), and there is a high likelihood of backwards incompatible changes being made to WebSockets's "ws:" protocol between different versions (-76, -00, -01).<br />
<br />
Thus it is worth considering prefixing implementations of the "ws:" protocol in order to break/rev as necessary instead of being locked into a specific draft due to premature reliant adoption.<br />
<br />
For all protocol schemes that are:<br />
* Proprietary. No standards organization draft yet published. OR<br />
* In a W3C or IETF working draft, not yet in a Candidate Recommendation, or perhaps public last call for IETF drafts (open to suggestions here).<br />
<br />
Use vendor prefixed protocol schemes as follows:<br />
<br />
<pre>vendor_prefix - unprefixed_name</pre><br />
<br />
E.g. WebSockets has a new ws: scheme, and we've implemented it in Firefox 4. We really should be using:<br />
<br />
<pre>moz-ws:</pre><br />
<br />
Our goal is to establish a convention (like the above) for all such pre-CR protocol schemes that has the consensus of implementers so that we can avoid creating broken versions of protocols.<br />
<br />
<br />
==== simple HTML attributes prefixes proposal ====<br />
Implementing prefixes on element names doesn't work because you can't have more than one element name per element, and thus prefixed versions would force developers to choose between unprefixed and a particular prefixed version.<br />
<br />
However elements do have multiple attributes, and thus prefixing can work for attributes.<br />
<br />
For all HTML attributes that are:<br />
* Proprietary. No standards organization draft yet published. OR<br />
* In a W3C working draft (e.g. New in HTML5), not yet in a Candidate Recommendation.<br />
<br />
Use vendor prefixed attributes as follows:<br />
<br />
<pre>vendor_prefix _ unprefixed_name</pre><br />
<br />
E.g. HTML5 has a new [http://www.w3.org/TR/html5/common-input-element-attributes.html#attr-input-pattern 'pattern' attribute], and we've implemented it in Firefox 4. We really should be using:<br />
<br />
<pre>moz_pattern</pre><br />
<br />
This works because standard HTML attributes do not use underscores.<br />
<br />
Our goal is to establish a convention (like the above) for all such pre-CR new HTML5 attributes that has the consensus of implementers so that we can avoid creating broken versions of elements.<br />
<br />
=== UI Layout ===<br />
CSS3 Flex Box and Grid<br />
<br />
There are two new CSS3 layout mechanisms being developed that could greatly assist with the layout of user interfaces.<br />
<br />
* CSS3 Flex Box<br />
** current working draft: http://www.w3.org/TR/css3-flexbox/<br />
** current editor's draft: http://dev.w3.org/csswg/css3-flexbox/ <br />
** Tab's proposed update: http://dev.w3.org/csswg/css3-flexbox/Overview.new.src.html<br />
** Tab's documentation of differences between editor's draft and his draft: http://www.xanthir.com/blog/b48Z0<br />
<br />
* CSS3 Grid<br />
** 2007-09-05 (current) working draft: http://www.w3.org/TR/css3-grid/<br />
** 2008-01-06 (current) editor's draft: http://dev.w3.org/csswg/css3-grid/<br />
<br />
* CSS3 Grid Align - not clear on the relation between Grid and Grid Align<br />
** Alex Mogilevsky's CSS3 Grid Align first draft: http://www.interoperabilitybridges.com/css3-grid-align/<br />
*** Alex's www-style email thread announcing his draft: http://lists.w3.org/Archives/Public/www-style/2010Oct/thread.html#msg787<br />
** 2010-11-18 (current) editor's draft: http://dev.w3.org/csswg/css3-grid-align/<br />
<br />
Some next-steps:<br />
* need to get in touch with Tab Atkins and catch-up on the current state of his Flex Box work vs. existing prefixed partial implementation in Firefox and Safari.<br />
** 2010-155 briefly spoke with Tab about flex box in irc and noted that I'm working on css3-color and css3-ui first.<br />
<br />
=== Full Screen ===<br />
;latest published draft (none)<br />
:none currently (TR URL when ready)<br />
;latest development / in progress draft<br />
:none currently ( dev.w3.org URL when ready)<br />
;spec source (for editing)<br />
:none currently ( dev.w3.org src.html URL when ready) <br />
;test suite<br />
:TBD<br />
;implementation reports of the test suite<br />
:TBD<br />
;issues list for the current draft<br />
:none currently (perhaps wiki.csswg.org URL when ready)<br />
<br />
==== remaining tasks ====<br />
* work with RoC on updating <br />
** https://wiki.mozilla.org/Gecko:FullScreenAPI<br />
* make sure feedback is incorporated from<br />
** http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-August/thread.html#27670<br />
<br />
==== waiting for ====<br />
* RoC on preferred forum for draft development (CSSWG suggested)<br />
** emailed 2011-080<br />
<br />
=== HTML5 spec improvements ===<br />
A set of tasks/projects for improving the state of the [[HTML5]] specification. Proposals will be moved to separate pages once mature enough for submission to [[standards]] bodies.<br />
<br />
Most of this has been moved to [[HTML5#spec_issues|HTML5: spec issues]].<br />
<br />
Next: follow-up on each, determining next steps on rejected proposals.<br />
<br />
==== waiting for HTML5 improvements ====<br />
==== keeping crappy stuff out ====<br />
===== simplify alt attribute guidance =====<br />
Moved to [[HTML5/img#alt_guidance_needs_simplification|HTML5/img]].<br />
===== remove meta Content-Language =====<br />
Moved to [[HTML5/meta#remove_meta_Content-Language|HTML5/meta]]<br />
==== upgrade HTML4 features to be more flexible and usable ====<br />
==== restoring pragmatic HTML4 things ====<br />
Moved to [[HTML5/cite#names_of_speakers|HTML5/cite]].<br />
==== improving new features ====<br />
===== iframe sandbox removal =====<br />
Moved to [[HTML5/iframe#drop_sandbox_attribute|HTML5/iframe]].<br />
===== summary naming =====<br />
Moved to [[HTML5/summary#summary_naming|HTML5/summary]]<br />
===== expand time =====<br />
Moved to [[HTML5/time#expand_time|HTML5/time]]<br />
===== nesting time =====<br />
Moved to [[HTML5/time#nesting_time|HTML5/time]]. am pm handling too.<br />
<br />
==== lower priority improvements ====<br />
* <code>&lt;meter&gt;</code> - poorly named. would prefer something like "gauge" but that's potentially hard(er) to spell. this is a bit bikesheddy though so not a high priority.<br />
<br />
<br />
== Web Apps Waiting For ==<br />
Tasks which are awaiting follow-ups from various standards bodies/lists. Reping as necessary to keep moving forward.<br />
<br />
=== CSS Waiting For ===<br />
==== CSS3 Backgrounds and Borders ====<br />
Waiting for CR of http://www.w3.org/TR/css3-background/<br />
<br />
And then: outstanding UI related issues:<br />
<br />
===== prefix removal from -moz-border-radius =====<br />
<br />
Currently Mozilla's border-radius properties are prefixed with -moz- and the following bugs/issues are preventing us from removing the prefix:<br />
<br />
* '''% values on border-radius.''' There is existing content (themes?) that depend on the legacy moz-border-radius implementation of % values that depend on the % of *width* in both dimensions.<br />
<br />
* '''clipping overflow and replaced elements.''' We don't currently clip overflow hidden and replaced elements (e.g. img, video, canvas) to rounded corners. We need to do to this for a proper/complete implementation that won't risk creating further legacy/backward compat problems.<br />
<br />
Bugzilla bugs:<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=431176 431176] - (border-radius) Tracking bug for remaining issues with CSS3 border-radius<br />
*[https://bugzilla.mozilla.org/show_bug.cgi?id=451134 451134] - change -moz-border-radius* properties to css3-background names<br />
<br />
== Social and Identity ==<br />
=== Related Features ===<br />
Features/people working with:<br />
* [[Account Manager]] - Dan Mills<br />
* Mozilla Contacts - Michael Hanson<br />
* Context Menu - Aza Raskin<br />
** see related: 2010-05-03 [http://mozillalabs.com/jetpack/2010/05/03/context-menu-module-microformats/ The Context Menu Module & Microformats] (JetPack)<br />
* ...<br />
<br />
=== Standards and Communities ===<br />
Standards and communities to engage with (recommended, grouped by related)<br />
<br />
identity / profiles / contacts<br />
* [[vCard4]] (IETF vcarddav)<br />
** write up problems with vCard4, divergence from vCard3/hCard/PoCo model, etc.<br />
* [[hCard]] (microformats.org)<br />
* Portable Contacts<br />
* microdata vcard vocab (W3C/WhatWG)<br />
* RelMeAuth<br />
* OpenID<br />
* WebFinger<br />
* ...<br />
<br />
social web<br />
* OAuth (including OAuth 2, xAuth, OWF)<br />
* Activity Streams<br />
* [http://federatedsocialweb.net/ Federated Social Web]<br />
* ...<br />
<br />
== Events ==<br />
See the [[Events]] page for event that I'm speaking or participating in accordingly.<br />
<br />
== Web Standards Coordination ==<br />
There are a lot of people at Mozilla working with a variety of different standards bodies. With Arun's recent departure, it's more clear than ever that we need to at least have some sort of a directory of standards organizations (and sub-orgs like working groups) listing who at Mozilla is working with each.<br />
<br />
* [[Standards]] - who is working on what standards in what organizations<br />
<br />
== Reference ==<br />
=== Pages ===<br />
See [[User:Tantek#pages|reference pages created]]<br />
<br />
=== Done ===<br />
Completed tasks, projects, events that have no further related active work items. Will likely move to its own page as it grows, in which case, I'll probably just keep *recently* finished items here and regularly archive them.<br />
<br />
==== Completed Events ====<br />
For more details on completed events, see the main [[Events]] page and its archives.<br />
===== Events 2011 =====<br />
* 2011-03-07...2011-03-09 CSS Working Group March 2011 meeting<br />
* 2011-03-10...2011-03-20 SXSW - spoke on microformats, gather input for HTML5<br />
* 2011-03-28...2011-03-31 Web 2.0 Expo - spoke on HTML5, gather input.<br />
* 2011-04-10 LinkedGov Data HackCamp - discussed role of microformats/browser in open data<br />
* 2011-04-13...2011-04-15 UX London - gather lots of CSS3-UI input<br />
* 2011-04-19...2011-04-21 Where 2.0 - gather input on GeoLocation additions, browser support for geo apps<br />
* 2011-04-22 WhereCampSF SF 2011 - gather input on browser support for geo apps<br />
<br />
===== Events 2010 =====<br />
* June 1-3 Open Source Bridge, Portland, OR, http://opensourcebridge.org<br />
* June 28-30 Voices That Matter Web Design in SF http://www.voicesthatmatter.com/webdesign2010<br />
* July 6-10 [[Summit2010|Mozilla Summit]] in Whistler, Canada.<br />
* July 13 [http://www.realestateconnect.com/program/ Real Estate Connect San Francisco] (click on "Workshops »", search for "HTML5") at Hilton San Francisco Union Square, 333 O'Farrell Street, San Francisco, California<br />
** participating in WORKSHOP: ConnectTech / HTML5 Is Coming, Are You Ready?<br />
* July 17 [http://openwebcamp.org OpenWebCamp II] at Stanford<br />
* July 18 [http://federatedsocialweb.net/wiki/Main_Page Federated social web summit] ([http://federatedsocialweb.net/wiki/Schedule schedule])<br />
** more info: [http://status.net/2010/06/28/federated-social-web-summit-2010-announced announcement], [http://federatedsocialweb.net/wiki/FedAll2010/Invitations attendees]<br />
* August 23-25 [http://www.w3.org/Style/Group/2010/Oslo W3C CSS WG f2f in Oslo]<br />
* September 1-3 [http://2010.dConstruct.org/ dConstruct in Brighton] - web design and development<br />
* September 9 [http://plancast.com/p/27av MozPub HTML5 meet, with Tantek Çelik] - gather input for HTML5 improvements<br />
* September 21-25 [http://usa10.webdirections.org/ Web Directions USA] - represent Mozilla in Browsers panel, gather input for HTML5, CSS3.<br />
* 2010-10-01...2010-10-02 Open Video Conference, gather input for HTML5 video/media etc.<br />
* 2010-10-03 OVC hack labs - gather input for HTML5 video/media etc.<br />
* 2010-10-08...2010-10-09 Open Web Foo - discuss/promote "Open Web" ideals with Mitchell<br />
* 2010-10-21...2010-10-22 Front Trends conference - speak on HTML5, gather HTML5 input<br />
* 2010-11-01 OpenID Technology Summit - spearhead identity/profile format convergence<br />
* 2010-11-08...2010-11-10 YUIConf - speak on HTML5, web future panel, gather input<br />
<br />
==== Resolved HTML5 improvements and spec issues ====<br />
===== reject longdesc =====<br />
moved to: [[HTML5/img#reject_longdesc|HTML5/img]]<br />
===== allow date only on del ins datetime attribute =====<br />
* moved to [[HTML5/del#datetime_should_take_date|HTML5/del]].<br />
<br />
==== CSS ====<br />
===== CSS Style Attributes =====<br />
* CSS Style Attributes - achieved CR!<br />
;latest published draft (CR)<br />
:http://www.w3.org/TR/css-style-attr/<br />
;latest development / in progress draft<br />
:http://dev.w3.org/csswg/css-style-attr/<br />
;spec source (for editing)<br />
:http://dev.w3.org/csswg/css-style-attr/Overview.src.html<br />
;test suite<br />
:TBD<br />
;implementation reports of the test suite<br />
:TBD<br />
;issues list for the current draft<br />
:http://wiki.csswg.org/spec/css-style-attr<br />
<br />
===== CSS3 Color =====<br />
* CSS3 Color draft - achieved PR!<br />
;latest published draft<br />
:http://www.w3.org/TR/css3-color/<br />
;latest development / in progress draft<br />
:http://dev.w3.org/csswg/css3-color/<br />
;spec source (for editing)<br />
:http://dev.w3.org/csswg/css3-color/Overview.src.html<br />
;test suite<br />
:http://www.w3.org/Style/CSS/Test/CSS3/Color/20080721/<br />
;implementation reports of the test suite<br />
:http://www.w3.org/Style/CSS/Test/CSS3/Color/current/reports/<br />
;issues list for the current last call<br />
:http://wiki.csswg.org/spec/css3-color<br />
<br />
===== CSS3 UI =====<br />
Updated [http://dev.w3.org/csswg/css3-ui/ CSS3 UI Editor's draft] with:<br />
====== pointer-events ======<br />
* add '''pointer-events''' A way of specifying whether an element is opaque to pointer events (and receives them) or is transparent to them (letting them get handled by what's underneath.<br />
** CSSWG wiki: http://wiki.csswg.org/ideas/pointer-events<br />
** https://developer.mozilla.org/en/css/pointer-events - Mozilla spec<br />
*** shipped in Firefox 3.6 - demo: http://demos.hacks.mozilla.org/openweb/pointer-events/ ([https://bugzilla.mozilla.org/show_bug.cgi?id=380573 bug 380573]).<br />
*** See also SVG version: https://wiki.mozilla.org/SVG:Pointer-events<br />
** http://webkit.org/specs/PointerEventsProperty.html - Webkit spec<br />
*** shipped in Safari 4.0 ([https://bugs.webkit.org/show_bug.cgi?id=11395 bug 11395])<br />
** [http://people.opera.com/lstorset/TR/pointer-events/ Opera proposal]<br />
*** [http://lists.w3.org/Archives/Public/www-style/2010Aug/0407.html email proposing]<br />
*** [http://people.opera.com/lstorset/TR/pointer-events/ED-pointer-events-20100820.html CSS Hit Testing]<br />
** related: [[SVG:Pointer-events]]<br />
** key issue: precisely define default behavior (auto or visible etc.)<br />
** pointer events should be defined to affect:<br />
*** application of cursor property<br />
*** :hover<br />
*** mouseevents<br />
*** touchevents<br />
*** general concept of hit-testing so that elementFromPoint can be defined in terms of it (feedback fron annevk).<br />
====== text-overflow ======<br />
* '''text-overflow'''. incorporated '[https://developer.mozilla.org/En/CSS/text-overflow text-overflow]', since it's more a UI/overflow thing than a typesetting thing. There are at least 3 implementations (IE, WebKit, Opera), and has a bug against Firefox: [https://bugzilla.mozilla.org/show_bug.cgi?id=312156 312156]<br />
** Wanted for post-FF4; mats will be working on it, needs spec<br />
** W3C: http://dev.w3.org/csswg/css3-text/#text-overflow<br />
*** http://www.w3.org/blog/CSS/2009/11/25/resolutions_84 for bidi discussions<br />
** DevMo: https://developer.mozilla.org/En/CSS/text-overflow<br />
** Webkit: http://developer.apple.com/library/safari/documentation/appleapplications/reference/SafariCSSRef/Articles/StandardCSSProperties.html#//apple_ref/doc/uid/TP30001266-SW24<br />
** Microsoft/IE: http://msdn.microsoft.com/en-us/library/ms531174(VS.85).aspx<br />
** write test cases for 'ellipsis' and 'clip' (default value) and confirm cross-browser support.<br />
** Details that [https://bugzilla.mozilla.org/show_bug.cgi?id=312156#c21 RoC wants]:<br />
*** What style the ellipsis has (font, color, etc) ... does it come from the text or does it come from the element with text-overflow on it?<br />
**** from the element with text-overflow on it, this is what WebKit and Opera do<br />
**** need test case to see what Webkit, IE, Opera do<br />
*** does text-overflow inherit by default or not?<br />
**** Inherited: no<br />
*** how does it work with text-align:right, does the ellipsis go on the left?<br />
**** text-align does not affect text-overflow<br />
*** how does it work with bidi text, e.g. a line of Hebrew?<br />
**** it is rendered according to the 'direction' of the element.<br />
*** What about mixed bidi text e.g. English followed by Hebrew? I'm particuarly interested in the case of an LTR word followed by an RTL word that doesn't fit, e.g. <pre>english WERBEH</pre>where only "english HEB" fits, where should the ellipsis go?<br />
**** "english BEH…"<br />
*** Can bidi text make the ellipsis appear at the beginning of the line? <br />
**** bidi text? no. howevrer, setting 'direction:rtl' on the element will cause any ellipses to be drawn on the left side.<br />
*** what happens if there's replaced content near the end of the line, say an image?<br />
**** the image would wrap to the next line. but if there is white-space:nowrap, then...<br />
*** Do you get the ellipsis or does the image overflow? <br />
**** Images never cause ellipsis (in current implementations) per https://bugzilla.mozilla.org/show_bug.cgi?id=312156#c28<br />
*** If an ellipsis, where does the ellipsis go?<br />
**** it goes instead of the image and any text you have to remove in order to make the ellipsis fit.<br />
** add http://farm4.static.flickr.com/3635/3571013052_d419aff822_s.jpg CSS IS AWESOME examples/tests to the spec<br />
** capture issues and undefined aspects from fantasai/RoC emails as of 2011-031.<br />
** clarify text per emails from fantasai/RoC<br />
*** the effect of text-overflow:ellipsis on lines whose line boxes are not direct children of the block box(es) with text-overflow.<br />
*** the behavior of text-overflow:ellipsis on a block with 'overflow' of 'scroll' (no good interop, ideal behavior documented, needs screenshots)<br />
**** testcase from RoC: http://lists.w3.org/Archives/Public/www-style/2011Jan/att-0669/test.html<br />
**** Safari scrolls the ellipsis ... and doesn't reveal any additional text - this doesn't make sense to me (RoC, nor me Tantek) as a user. If I scroll I should get to see the rest of the content. (Agreed)<br />
**** Opera scrolls the text into view until the you can see the end of the text at which point the block scrolls no further (this is ideal beahvior -t). No ellipsis is display on the otherside of the block when you start scrolling characters off the start edge.<br />
***** This seems like the best behavior so far, with the exception that as a user (and developer) I'd expect to see the text that scrolled off the start of the block get replaced by an ellipsis rather than simply clipped (agreed precisely with RoC on this and have specified this expected behavior as a SHOULD)<br />
**** Testing IE9 in standards mode showed same behavior as Safari for scrolling+ellipsis.</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Features/Inbox&diff=302487Features/Inbox2011-04-25T23:56:12Z<p>Fantasai: /* The List */</p>
<hr />
<div>If you have an item you would like to add to the [[Features|Feature List]], you must first [[Features/Planning_and_Tracking#If_your_Feature_doesn.27t_have_a_Feature_page|create a Feature Page]] for it, including enough information in the page that the triage team will be able to understand what you're proposing.<br />
<br />
Once you have a Feature Page filled out, you should then link to it here. Once per week the team will triage the Inbox, sort out priorities, and add them to the corresponding lists. The team may have follow up questions, so please be sure to include your name and contact information when linking to your Feature page or in the Feature page itself.<br />
<br />
'''Anyone is welcome to propose a feature this way''' -- this is not restricted to particular people or teams. If you have any questions, please contact [[User:Dria|Deb]].<br />
<br />
== The List ==<br />
<section begin="inboxtriage" />last triaged: 2011/04/12 :: '''Next triage expected to be week of May 2nd'''<section end="inboxtriage" /> (Jay's away until then)<br />
<br />
{| class="fullwidth-table sortable" style="width: 950px"<br />
|-<br />
| style="font-weight: bold; background: #DDD; width: 100px" | Roadmap<br />
| style="font-weight: bold; background: #DDD; width: 100px" | Team<br />
| style="font-weight: bold; background: #DDD;" | Feature<br />
| style="font-weight: bold; background: #DDD; width: 50px" | Rank<br />
| style="font-weight: bold; background: #DDD; width: 150px" | Owner<br />
|-<br />
| Privacy<br />
| Platform (?)<br />
| [[Privacy/Features/DOMCryptAPI]]<br />
| Untriaged<br />
| Dave Dahl<br />
|-<br />
| Add-ons<br />
| Front-end<br />
| [[Extension Manager:Projects:Appearance Pane|Improved themes and personas selection]]<br />
| Untriaged - P2?<br />
| Mossop<br />
|-<br />
| Add-ons<br />
| Front-end<br />
| [[Extension Manager:Projects:Search Engines|Integrate search engines into the add-ons manager]]<br />
| Untriaged - P3?<br />
| Mossop<br />
|-<br />
| Add-ons<br />
| Front-end<br />
| [[Extension Manager:Projects:Uninstalling Third Party Add-ons|Allow uninstalling third-party installed add-ons]]<br />
| Untriaged - P3?<br />
| Mossop<br />
|-<br />
| Add-ons<br />
| Front-end<br />
| [[Extension Manager:Projects:Embedded Add-on Preferences|Simple options for add-ons embedded in the main UI]]<br />
| Untriaged - P3?<br />
| Mossop<br />
|-<br />
| User Engagement<br />
| Front-end<br />
| [[Firefox/Input/Standalone_Feedback_Button|Provide a standalone feedback button]]<br />
| Untriaged - P3?<br />
| aakashd<br />
|-<br />
| Web platform<br />
| Content<br />
| [[Platform/Features/Input_Number|Implement <input type='number'>]]<br />
| Untriaged - P3?<br />
| Mounir Lamouri<br />
|-<br />
| Installers<br />
| Front-end<br />
| [[Firefox/Features/InstallerUIRewrite|Installer UI Rewrite]]<br />
| Untriaged - P1?<br />
| Robert Strong<br />
|-<br />
| Mobile<br />
| UX<br />
| [[Fennec/Features/Gestures]]<br />
| Untriaged<br />
| Thomas Arend<br />
|-<br />
| JavaScript<br />
| JavaScript<br />
| [[Platform/Features/IonMonkey|IonMonkey]]<br />
| Untriaged<br />
| David Anderson<br />
|-<br />
| Layout<br />
| Layout<br />
| [[https://bugzilla.mozilla.org/show_bug.cgi?id=652650|Pretty Borders]]<br />
| Needs a feature page.<br />
| fantasai / Anil<br />
|-<br />
| UX<br />
| Front-end<br />
| [[Firefox/Features/windows-scrolling|Support high resolution scrolling on windows]]<br />
| Untriaged<br />
| Faaborg<br />
|-<br />
| UX<br />
| Front-end<br />
| [[Firefox/Features/streamline-search|Streamline the visual appearance of the search field]]<br />
| Untriaged<br />
| Faaborg<br />
|-<br />
| UX<br />
| Front-end<br />
| [[Firefox/Features/Show_infobar_session_restore|Show infobar for session restore if custom home page]]<br />
| Untriaged<br />
| Alex Limi<br />
|-<br />
| UX<br />
| Front-end<br />
| [[Extension Manager:Projects:Improve_Add-on_Installation|Improve Add-on Installation]] <br />
| Untriaged<br />
| Jennifer Boriss<br />
|}</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Features/Platform&diff=302377Features/Platform2011-04-25T19:55:27Z<p>Fantasai: /* Features List */</p>
<hr />
<div>This list needs to be divided into smaller lists by team (with team names added to column 2):<br />
* Platform (Gecko?)<br />
* GFX<br />
* JS<br />
* Layout<br />
* Video<br />
* Plugins<br />
* Content<br />
* Any others needed...<br />
<br />
PMs and relevant teams should review these lists by '''as soon as possible''' and:<br />
# add/modify/remove items as needed<br />
# sort the items by priority order from most to least important<br />
<br />
Note that this is in addition to the P1/P2/P3 bucketing, and everything should end up in a no-ties rank ordering (1, 2, 3, etc.) '''Where there are currently ties in the resulting smaller lists (for example: multiple ''P1 (1)'' items) please resolve these so the P1 items have no ties.'''<br />
<br />
If you have any questions, please contact [[User:Dria|Deb]].<br />
<br />
== Features List ==<br />
{| class="fullwidth-table sortable" style="width: 950px"<br />
|-<br />
| style="font-weight: bold; background: #DDD; width: 100px" | Roadmap<br />
| style="font-weight: bold; background: #DDD; width: 100px" | Team<br />
| style="font-weight: bold; background: #DDD;" | Feature<br />
| style="font-weight: bold; background: #DDD; width: 50px" | Rank<br />
| style="font-weight: bold; background: #DDD; width: 150px" | Owner<br />
|-<br />
| Add-ons<br />
| Jetpack<br />
| Out-of-process add-ons <br />
| {{Pr1}} (1)<br />
| Myk Melez<br />
|-<br />
| DevTools<br />
| JavaScript<br />
| [[DevTools/Features/JSD2|New JavaScript Debugging]]<br />
| {{Pr1}} (1)<br />
| Kevin Dangoor<br />
|-<br />
| Identity<br />
| --<br />
| Web APIs for verified email based sign-in <br />
| {{Pr1}} (1)<br />
| Dan Mills<br />
|-<br />
| Plugins<br />
| Content<br />
| Bundled/Native Plugin Support (including upgrade) <br />
| {{Pr1}} (1)<br />
| Kev Needham<br />
|-<br />
| Telemetry<br />
| Performance<br />
| [[Platform/Features/Telemetry|Telemetry]]<br />
| {{Pr1}} (1)<br />
| Chris Blizzard<br />
|-<br />
| Add-ons<br />
| Jetpack<br />
| window-independent content frames <br />
| {{Pr1}} (2)<br />
| Myk Melez<br />
|-<br />
| DevTools<br />
| Multiple<br />
| [[DevTools/Features/FirebugStability|Firebug Stability and Performance]]<br />
| {{Pr1}} (2)<br />
| Kevin Dangoor<br />
|-<br />
| Privacy<br />
| Network?<br />
| [[Privacy/Features/Shortened HTTP Referer header|Shortened HTTP Referer header]]<br />
| {{Pr1}} (2)<br />
| Sid Stamm<br />
|-<br />
| Web platform<br />
| Layout and Content<br />
| [[Platform/Features/Full Screen APIs|Full Screen APIs]]<br />
| {{Pr1}} (2)<br />
| Chris Blizzard<br />
|-<br />
| Networking<br />
| Networking<br />
| [[Platform/Features/Websockets|Websockets]]<br />
| {{Pr1}} (3)<br />
| Chris Blizzard<br />
|-<br />
| Web platform<br />
| Layout<br />
| text-overflow: ellipsis <br />
| {{Pr1}} (4)<br />
| Chris Blizzard<br />
|-<br />
| Web platform<br />
| Content<br />
| Web timing spec <br />
| {{Pr1}} (5)<br />
| Chris Blizzard<br />
|-<br />
| Plugins<br />
| Content<br />
| OOPP Tuning and Expansion to better support existing and additional plugins <br />
| {{Pr1}} (6)<br />
| Kev Needham <br />
|-<br />
| UX<br />
| Content<br />
| [[Firefox/Features/XBL_Reduction|Reduce/Reduce performance impact of XBL]]<br />
| {{Pr1}} (6)<br />
| Jay Sullivan<br />
|-<br />
| Web platform<br />
| Content and Mobile<br />
| Touch and Multi-touch events for mobile <br />
| {{Pr1}} (6)<br />
| Chris Blizzard<br />
|-<br />
| Web platform<br />
| Content<br />
| IndexedDB for Mobile <br />
| {{Pr1}} (7)<br />
| Chris Blizzard<br />
|-<br />
| Applications<br />
| Layout and Standards<br />
| Scoping Application Layout models (grid/flex) <br />
| {{Pr1}} (8)<br />
| Chris Blizzard<br />
|-<br />
| DevTools<br />
| Multiple<br />
| [[DevTools/Features/Memory|Memory Tooling Backend]]<br />
| {{Pr1}} (8)<br />
| Kevin Dangoor<br />
|-<br />
| Web platform<br />
| Content<br />
| EventSource events over HTTP <br />
| {{Pr1}} (9)<br />
| Chris Blizzard<br />
|-<br />
| Applications<br />
| Content and Apps<br />
| Expanded capabilities for Workers (needs scoping)<br />
| {{Pr2}}<br />
| Chris Blizzard<br />
|-<br />
| Applications<br />
| Content<br />
| Scoping library loading APIs<br />
| {{Pr2}}<br />
| Chris Blizzard<br />
|-<br />
| Applications<br />
| Content and Apps<br />
| Scoping headless applications and activation for Applications<br />
| {{Pr2}}<br />
| Chris Blizzard<br />
|-<br />
| Applications<br />
| Apps<br />
| Scoping messaging for Applications<br />
| {{Pr2}}<br />
| Chris Blizzard<br />
|-<br />
| Gecko<br />
| GFX<br />
| Scoping GFX revamp<br />
| {{Pr2}}<br />
| Chris Blizzard<br />
|-<br />
| Gecko<br />
| Content and Apps<br />
| Scoping Process/Platform changes for multi-process apps and tabs<br />
| {{Pr2}}<br />
| Chris Blizzard <br />
|-<br />
| Identity<br />
| --<br />
| API experiment<br />
| {{Pr2}}<br />
| Dan Mills<br />
|-<br />
| Networking<br />
| Networking<br />
| HTTP Pipelining on by default <br />
| {{Pr2}} <br />
| Chris Blizzard<br />
|-<br />
| Networking<br />
| Networking<br />
| Scoping priorities for HTTP caches<br />
| {{Pr2}}<br />
| Chris Blizzard<br />
|-<br />
| Plugins<br />
| Content<br />
| Update plugins with no restart required<br />
| {{Pr2}}<br />
| Kev Needham<br />
|-<br />
| Privacy<br />
| Content<br />
| [[Privacy/Features/Third-Party-Cookie Request API|API for sites to request use of third-party cookies]]<br />
| {{Pr2}}<br />
| Sid Stamm<br />
|-<br />
| Privacy<br />
| Content<br />
| [[Privacy/Features/Capability API|API for sites to request additional sensitive features like geolocation, a:ping, local storage, etc.]] <br />
| {{Pr2}}<br />
| Sid Stamm<br />
|-<br />
| Privacy<br />
| Content<br />
| [[Privacy/Features/Geoloc Auto-discover Disabling|disable automated discovery for Geolocation]]<br />
| {{Pr2}}<br />
| Sid Stamm<br />
|-<br />
| Privacy<br />
| Content<br />
| [[Privacy/Features/2factor in the browser|API for sites to trigger second-factor authentication (e.g., SMS)]]<br />
| {{Pr2}}<br />
| Sid Stamm<br />
|-<br />
| Privacy<br />
| Network?<br />
| [[Privacy/Features/Low-Entropy Private Browsing|Reduce fingerprint-ability in private browsing]]<br />
| {{Pr2}}<br />
| Sid Stamm<br />
|-<br />
| Privacy<br />
| Content<br />
| [[Privacy/Features/NPAPI Privacy Settings|Plugin awareness of users privacy prefs]]<br />
| {{Pr2}}<br />
| Sid Stamm<br />
|-<br />
| Privacy<br />
| Network<br />
| [[Privacy/Features/cert-received observer topic|Check-point API between TLS/SSL handshake and HTTP request]]<br />
| {{Pr2}}<br />
| Sid Stamm<br />
|-<br />
| UX<br />
| Mac Integration<br />
| OS X 10.7 features: scrollbar, full screen mode, three-finger gestures<br />
| {{Pr2}} <br />
| Alex Limi<br />
|-<br />
| UX<br />
| Mac Integration<br />
| Ability to put tabs in title bar on OS X<br />
| {{Pr2}} <br />
| Alex Limi<br />
|-<br />
| Web platform<br />
| Networking<br />
| TLS False Start<br />
| {{Pr2}}<br />
| Chris Blizzard<br />
|-<br />
| Web platform<br />
| Layout<br />
| CSS 2.1 tests fallout<br />
| {{Pr2}}<br />
| Chris Blizzard<br />
|-<br />
| Web platform<br />
| Layout<br />
| CSS 3 Backgrounds<br />
| {{Pr2}}<br />
| Chris Blizzard<br />
|-<br />
| Web platform<br />
| Layout<br />
| 3D transforms<br />
| {{Pr2}}<br />
| Chris Blizzard<br />
|-<br />
| Web platform<br />
| Layout<br />
| Flawless switching of audio when going from in-page to full screen<br />
| {{Pr2}}<br />
| Chris Blizzard<br />
|-<br />
| Web platform<br />
| Mobile and Content<br />
| Taking a picture from a web page<br />
| {{Pr2}}<br />
| Chris Blizzard<br />
|-<br />
| Web platform<br />
| Content<br />
| Notifications on desktop<br />
| {{Pr2}}<br />
| Chris Blizzard<br />
|-<br />
| Web platform<br />
| Networking<br />
| Proper support for Content-disposition (Done for Firefox 5)<br />
| {{Pr2}}<br />
| Chris Blizzard<br />
|-<br />
| Web platform<br />
| GFX<br />
| WebP Support<br />
| {{Pr2}}<br />
| Chris Blizzard<br />
|-<br />
| Web platform<br />
| Layout<br />
| Scoping Content Editable Changes<br />
| {{Pr2}}<br />
| Chris Blizzard<br />
|-<br />
| Web platform<br />
| Layout<br />
| Real time audio and video<br />
| {{Pr2}}<br />
| Chris Blizzard<br />
|-<br />
| Web platform<br />
| Layout<br />
| Scoping multi-track audio and video<br />
| {{Pr2}}<br />
| Chris Blizzard<br />
|-<br />
| Web platform<br />
| Layout<br />
| Scoping variable-bitrate HTML5 video over HTTP<br />
| {{Pr2}}<br />
| Chris Blizzard<br />
|-<br />
| Privacy<br />
| Content<br />
| [[Privacy/Features/Geolocation Faking|Location faking for geolocation]]<br />
| {{Pr3}}<br />
| Sid Stamm<br />
|-<br />
| Privacy<br />
| Content<br />
| [[Privacy/Features/Disable Third-Party Cookies|Disable third-party cookie sending by default]]<br />
| {{Pr3}}<br />
| Sid Stamm <br />
|-<br />
| UX<br />
| Content<br />
| Event that signals when page is usable (progress indicator)<br />
| {{Pr3}}<br />
| Alex Limi<br />
|-<br />
| JavaScript<br />
| JavaScript<br />
| [[Platform/Features/IonMonkey|IonMonkey]]<br />
| <br />
| David Anderson<br />
|-<br />
| Layout<br />
| Layout<br />
| Pretty Borders<br />
| <br />
| fantasai / Anil<br />
|}<br />
<br />
[[Category:Features]]<br />
[[Category:Platform]]</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Community:SummerOfCode11:Brainstorming&diff=288609Community:SummerOfCode11:Brainstorming2011-03-03T20:12:44Z<p>Fantasai: /* Mozilla Platform */ fix markup error</p>
<hr />
<div> <br />
This page is for anyone to submit ideas for Google Summer of Code projects with Mozilla for 2011. As it is open to all, it will inevitably contain suggestions of wildly variable quality. <br />
<br />
<b>Students: ideas approved by the SoC admins are [[Community:SummerOfCode11|here]].</b> You can also submit ideas from this page, but they are rather less likely to be accepted. (There's probably a reason they haven't been moved to that page.) <b>You can also submit your own ideas - you don't have to put an idea on this page and get it made official in order to propose it.</b><br />
<br />
==How To Make Good Suggestions==<br />
<br />
Before adding an idea to this list, please consider the following:<br />
<br />
* '''Be specific'''. It's hard to understand the impact of, or the size of, vague proposals.<br />
* '''Consider size'''. The student has eight weeks to design, code, test and document the proposal. It needs to fill, but not overfill, that time.<br />
* '''Do your research'''. Support the idea with well-researched links.<br />
* '''Don't morph other people's ideas'''. If you have a related idea, place it next to the existing one, or add a comment. <br />
* '''Insert only your own name into the Mentor column''', and then only if you are willing to take on the responsibility. If you think the SoC admins won't know you, leave contact details.<br />
* '''Check back regularly'''. The administrators may have questions about your idea that you will need to answer.<br />
* '''Know when to give up'''. If you've added the same idea for the last three years and it hasn't made it to the official page, perhaps you can predict what will happen this time.<br />
<br />
==Suggestion List==<br />
<br />
[[SummerOfCode|Links to ideas lists from previous years]].<br />
<br />
==Mozilla Platform==<br />
<br />
{| class="standard-table"<br />
|-<br />
!Title<br />
!Details - with links as appropriate<br />
!Reporter<br />
!Mentor(s)<br />
!Comments<br />
|-<br />
|Improve Cairo performance to match Skia<br />
|There are a number of areas where [http://code.google.com/p/skia/ Skia] outperforms [http://www.cairographics.org/ Cairo]. Find them, and improve Cairo to match or exceed Skia's performance.<br />
|jrmuizel<br />
|jrmuizel<br />
|<br />
|-<br />
|Improve border corner joins<br />
|Our rendering of CSS border corners is very sloppy, particularly when the corner is rounded or when two styles intersect. You could code [https://bugzilla.mozilla.org/show_bug.cgi?id=382721 dotted and dashed rounded corners] and/or improve their [https://bugzilla.mozilla.org/show_bug.cgi?id=19963 interaction with other styles], or work on making other joins prettier.<br />
|fantasai<br />
|fantasai<br />
|-<br />
|Create a JPEG XR decoding library<br />
|[http://en.wikipedia.org/wiki/JPEG_XR JPEG XR] gives us better compression and other useful features like HDR and alpha channels. The library should be as similar to libjpeg as possible. It would be a "from scratch", freely licensed version and will need a student that is very comfortable with image compression and as has ideally written decompressors from scratch before.<br />
|jrmuizel<br />
|jrmuizel<br />
|<br />
|-<br />
|Implement HTML Speech proposal<br />
|[http://www.w3.org/2005/Incubator/htmlspeech/charter HTML Speech XG] will have a proposal for integrating speech recognition and text-to-speech functionality to web pages. Google has proposed already one [http://www.w3.org/2005/Incubator/htmlspeech/2010/10/google-api-draft.html API], but it is expected that the proposal from XG won't look exactly like that. For implementation [http://mozillalabs.com/rainbow/ Rainbow] can be useful.<br />
|smaug<br />
|smaug<br />
|davidb: Hey Olli, regarding tts, have you seen Google's [http://code.google.com/chrome/extensions/trunk/experimental.tts.html experimental impl]?<br />
<br />
No, I hadn't seen that, but there is more reasonable <br />
[http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Nov/att-0036/htmltts-draft.html proposal]<br />
|-<br />
|}<br />
<br />
==Firefox==<br />
<br />
{| class="standard-table"<br />
|-<br />
!Title<br />
!Details - with links as appropriate<br />
!Reporter<br />
!Mentor(s)<br />
!Comments<br />
|-<br />
|Unified Communications add-on<br />
|Develop the base for an add-on that creates a unified messaging UI inside browser tabs, following the [http://wiki.kairo.at/wiki/RMD RMD concept]. This should work with feed display and twitter integration in the beginning, but extensible to be able to support other communications later.<br />
|KaiRo<br />
|KaiRo<br />
|Not sure if this belongs in Firefox but there's no add-ons category.<br />
|}<br />
<br />
==Thunderbird==<br />
<br />
{| class="standard-table"<br />
|-<br />
!Title<br />
!Details - with links as appropriate<br />
!Reporter<br />
!Mentor(s)<br />
!Comments<br />
|}<br />
<br />
== Calendar ==<br />
<br />
{| class="standard-table"<br />
|-<br />
! Title <br />
! Details - with links as appropriate <br />
! Reporter <br />
! Mentor(s) <br />
! Comments<br />
|}<br />
<br />
==Camino==<br />
<br />
See the [http://wiki.caminobrowser.org/Development:Good_Bugs_and_Projects Camino Summer of Code page] for project suggestions.<br />
<br />
==SeaMonkey==<br />
<br />
{| class="standard-table"<br />
|-<br />
!Title<br />
!Details - with links as appropriate<br />
!Reporter<br />
!Mentor(s)<br />
!Comments<br />
|}<br />
<br />
==NSS (Network Security Services)==<br />
<br />
{| class="standard-table"<br />
|-<br />
! Title <br />
! Details - with links as appropriate <br />
! Reporter <br />
! Mentor(s) <br />
! Comments<br />
|-<br />
| OCSP improvements<br />
| Implement server-side OCSP stapling. (A patch for client-side OCSP stapling exists.) Implement client-side disk cache of OCSP responses.<br />
| Wan-Teh Chang<br />
| Wan-Teh Chang<br />
| You must be an experienced C programmer and can work full time on the project.<br />
|-<br />
| New crypto algorithms for NSS softoken<br />
| Add DSA with key sizes > 1024 bits (bug 475578); modes of operation for AES: GCM (bug 373108), CTR (bug 373106), CFB (bug 358219); and TLS 1.2 PRF to the NSS softoken.<br />
| Wan-Teh Chang<br />
| Wan-Teh Chang<br />
| You must be an experienced C programmer and can work full time on the project.<br />
|}<br />
<br />
== Bugzilla ==<br />
<br />
{| class="standard-table"<br />
|-<br />
! Title <br />
! Details - with links as appropriate <br />
! Reporter <br />
! Mentor(s) <br />
! Comments<br />
|}<br />
<br />
==Mobile/Fennec==<br />
<br />
{| class="standard-table"<br />
|-<br />
!Title<br />
!Details - with links as appropriate<br />
!Reporter<br />
!Mentor(s)<br />
!Comments<br />
|-<br />
|}<br />
<br />
==Firefox Support (Sumo)==<br />
<br />
{| class="standard-table"<br />
|-<br />
!Title<br />
!Details - with links as appropriate<br />
!Reporter<br />
!Mentor(s)<br />
!Comments<br />
|-<br />
|A real MediaWiki parser for Python<br />
|There are no MediaWiki parsers for Python with extensible syntax or multiple output formats. We've felt this pain in SUMO, which uses MW syntax in its knowledge base, resulting in hacks upon hacks to support features like platform-sensitive content, inclusions, and templates. We propose to implement [[Community:SummerOfCode11:MediaWikiParser|a new MW parser]] that generates proper parse trees, allows for pluggable syntax, and does not drive callers out of their minds.<br />
|ErikRose<br />
|ErikRose<br />
|<br />
|-<br />
|}<br />
<br />
==Rhino==<br />
<br />
{| class="standard-table"<br />
|-<br />
!Title<br />
!Details - with links as appropriate<br />
!Reporter<br />
!Mentor(s)<br />
!Comments <br />
|}<br />
<br />
==Mozilla IT Infrastructure==<br />
<br />
{| class="standard-table"<br />
|-<br />
!Title<br />
!Details - with links as appropriate<br />
!Reporter<br />
!Mentor(s)<br />
!Comments<br />
|}<br />
<br />
== Mozilla Services (Sync, Identity, etc) ==<br />
<br />
{| class="standard-table"<br />
|-<br />
!Title<br />
!Details - with links as appropriate<br />
!Reporter<br />
!Mentor(s)<br />
!Comments<br />
|}<br />
<br />
==Developer Tools==<br />
<br />
{| class="standard-table"<br />
|-<br />
!Title<br />
!Details - with links as appropriate<br />
!Reporter<br />
!Mentor(s)<br />
!Comments<br />
|-<br />
|'''Tilt'''<br />
|A WebGL-based 3D visualization of a Webpage. The developer will create a WebGL representation of a web-page that allows a user to rotate the page through axes to see the nesting of DOM nodes within the document. Floats and absolute positioned elements will be visible above and below the page based on their z-index. Tilt will be used as an additional visualization tool as part of a next-generation web page inspector.<br />
| Rob Campbell<br />
| Rob Campbell<br />
| Candidate must be proficient in JavaScript, DOM programming and have a good grasp of 3D graphics preferably some WebGL or OpenGL experience.<br />
|}<br />
<br />
==Drumbeat/Batucada==<br />
<br />
Any hacking projects connected to a [http://www.drumbeat.org/ Drumbeat] project or [https://wiki.mozilla.org/Drumbeat/Batucada Batucada].<br />
<br />
{| class="standard-table"<br />
|-<br />
!Title<br />
!Details - with links as appropriate<br />
!Reporter<br />
!Mentor(s)<br />
!Comments<br />
|}</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Community:SummerOfCode11:Brainstorming&diff=288607Community:SummerOfCode11:Brainstorming2011-03-03T20:11:37Z<p>Fantasai: /* Mozilla Platform */ add corner joins issue</p>
<hr />
<div> <br />
This page is for anyone to submit ideas for Google Summer of Code projects with Mozilla for 2011. As it is open to all, it will inevitably contain suggestions of wildly variable quality. <br />
<br />
<b>Students: ideas approved by the SoC admins are [[Community:SummerOfCode11|here]].</b> You can also submit ideas from this page, but they are rather less likely to be accepted. (There's probably a reason they haven't been moved to that page.) <b>You can also submit your own ideas - you don't have to put an idea on this page and get it made official in order to propose it.</b><br />
<br />
==How To Make Good Suggestions==<br />
<br />
Before adding an idea to this list, please consider the following:<br />
<br />
* '''Be specific'''. It's hard to understand the impact of, or the size of, vague proposals.<br />
* '''Consider size'''. The student has eight weeks to design, code, test and document the proposal. It needs to fill, but not overfill, that time.<br />
* '''Do your research'''. Support the idea with well-researched links.<br />
* '''Don't morph other people's ideas'''. If you have a related idea, place it next to the existing one, or add a comment. <br />
* '''Insert only your own name into the Mentor column''', and then only if you are willing to take on the responsibility. If you think the SoC admins won't know you, leave contact details.<br />
* '''Check back regularly'''. The administrators may have questions about your idea that you will need to answer.<br />
* '''Know when to give up'''. If you've added the same idea for the last three years and it hasn't made it to the official page, perhaps you can predict what will happen this time.<br />
<br />
==Suggestion List==<br />
<br />
[[SummerOfCode|Links to ideas lists from previous years]].<br />
<br />
==Mozilla Platform==<br />
<br />
{| class="standard-table"<br />
|-<br />
!Title<br />
!Details - with links as appropriate<br />
!Reporter<br />
!Mentor(s)<br />
!Comments<br />
|-<br />
|Improve Cairo performance to match Skia<br />
|There are a number of areas where [http://code.google.com/p/skia/ Skia] outperforms [http://www.cairographics.org/ Cairo]. Find them, and improve Cairo to match or exceed Skia's performance.<br />
|jrmuizel<br />
|jrmuizel<br />
|<br />
|-<br />
|Improve border corner joins<br />
|Our rendering of CSS border corners is very sloppy, particularly when the corner is rounded or when two styles intersect. You could code [https://bugzilla.mozilla.org/show_bug.cgi?id=382721|dotted and dashed rounded corners] and/or improve their [https://bugzilla.mozilla.org/show_bug.cgi?id=19963|interaction with other styles], or work on making other joins prettier.<br />
|fantasai<br />
|fantasai<br />
|-<br />
|Create a JPEG XR decoding library<br />
|[http://en.wikipedia.org/wiki/JPEG_XR JPEG XR] gives us better compression and other useful features like HDR and alpha channels. The library should be as similar to libjpeg as possible. It would be a "from scratch", freely licensed version and will need a student that is very comfortable with image compression and as has ideally written decompressors from scratch before.<br />
|jrmuizel<br />
|jrmuizel<br />
|<br />
|-<br />
|Implement HTML Speech proposal<br />
|[http://www.w3.org/2005/Incubator/htmlspeech/charter HTML Speech XG] will have a proposal for integrating speech recognition and text-to-speech functionality to web pages. Google has proposed already one [http://www.w3.org/2005/Incubator/htmlspeech/2010/10/google-api-draft.html API], but it is expected that the proposal from XG won't look exactly like that. For implementation [http://mozillalabs.com/rainbow/ Rainbow] can be useful.<br />
|smaug<br />
|smaug<br />
|davidb: Hey Olli, regarding tts, have you seen Google's [http://code.google.com/chrome/extensions/trunk/experimental.tts.html experimental impl]?<br />
<br />
No, I hadn't seen that, but there is more reasonable <br />
[http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Nov/att-0036/htmltts-draft.html proposal]<br />
|-<br />
|}<br />
<br />
==Firefox==<br />
<br />
{| class="standard-table"<br />
|-<br />
!Title<br />
!Details - with links as appropriate<br />
!Reporter<br />
!Mentor(s)<br />
!Comments<br />
|-<br />
|Unified Communications add-on<br />
|Develop the base for an add-on that creates a unified messaging UI inside browser tabs, following the [http://wiki.kairo.at/wiki/RMD RMD concept]. This should work with feed display and twitter integration in the beginning, but extensible to be able to support other communications later.<br />
|KaiRo<br />
|KaiRo<br />
|Not sure if this belongs in Firefox but there's no add-ons category.<br />
|}<br />
<br />
==Thunderbird==<br />
<br />
{| class="standard-table"<br />
|-<br />
!Title<br />
!Details - with links as appropriate<br />
!Reporter<br />
!Mentor(s)<br />
!Comments<br />
|}<br />
<br />
== Calendar ==<br />
<br />
{| class="standard-table"<br />
|-<br />
! Title <br />
! Details - with links as appropriate <br />
! Reporter <br />
! Mentor(s) <br />
! Comments<br />
|}<br />
<br />
==Camino==<br />
<br />
See the [http://wiki.caminobrowser.org/Development:Good_Bugs_and_Projects Camino Summer of Code page] for project suggestions.<br />
<br />
==SeaMonkey==<br />
<br />
{| class="standard-table"<br />
|-<br />
!Title<br />
!Details - with links as appropriate<br />
!Reporter<br />
!Mentor(s)<br />
!Comments<br />
|}<br />
<br />
==NSS (Network Security Services)==<br />
<br />
{| class="standard-table"<br />
|-<br />
! Title <br />
! Details - with links as appropriate <br />
! Reporter <br />
! Mentor(s) <br />
! Comments<br />
|-<br />
| OCSP improvements<br />
| Implement server-side OCSP stapling. (A patch for client-side OCSP stapling exists.) Implement client-side disk cache of OCSP responses.<br />
| Wan-Teh Chang<br />
| Wan-Teh Chang<br />
| You must be an experienced C programmer and can work full time on the project.<br />
|-<br />
| New crypto algorithms for NSS softoken<br />
| Add DSA with key sizes > 1024 bits (bug 475578); modes of operation for AES: GCM (bug 373108), CTR (bug 373106), CFB (bug 358219); and TLS 1.2 PRF to the NSS softoken.<br />
| Wan-Teh Chang<br />
| Wan-Teh Chang<br />
| You must be an experienced C programmer and can work full time on the project.<br />
|}<br />
<br />
== Bugzilla ==<br />
<br />
{| class="standard-table"<br />
|-<br />
! Title <br />
! Details - with links as appropriate <br />
! Reporter <br />
! Mentor(s) <br />
! Comments<br />
|}<br />
<br />
==Mobile/Fennec==<br />
<br />
{| class="standard-table"<br />
|-<br />
!Title<br />
!Details - with links as appropriate<br />
!Reporter<br />
!Mentor(s)<br />
!Comments<br />
|-<br />
|}<br />
<br />
==Firefox Support (Sumo)==<br />
<br />
{| class="standard-table"<br />
|-<br />
!Title<br />
!Details - with links as appropriate<br />
!Reporter<br />
!Mentor(s)<br />
!Comments<br />
|-<br />
|A real MediaWiki parser for Python<br />
|There are no MediaWiki parsers for Python with extensible syntax or multiple output formats. We've felt this pain in SUMO, which uses MW syntax in its knowledge base, resulting in hacks upon hacks to support features like platform-sensitive content, inclusions, and templates. We propose to implement [[Community:SummerOfCode11:MediaWikiParser|a new MW parser]] that generates proper parse trees, allows for pluggable syntax, and does not drive callers out of their minds.<br />
|ErikRose<br />
|ErikRose<br />
|<br />
|-<br />
|}<br />
<br />
==Rhino==<br />
<br />
{| class="standard-table"<br />
|-<br />
!Title<br />
!Details - with links as appropriate<br />
!Reporter<br />
!Mentor(s)<br />
!Comments <br />
|}<br />
<br />
==Mozilla IT Infrastructure==<br />
<br />
{| class="standard-table"<br />
|-<br />
!Title<br />
!Details - with links as appropriate<br />
!Reporter<br />
!Mentor(s)<br />
!Comments<br />
|}<br />
<br />
== Mozilla Services (Sync, Identity, etc) ==<br />
<br />
{| class="standard-table"<br />
|-<br />
!Title<br />
!Details - with links as appropriate<br />
!Reporter<br />
!Mentor(s)<br />
!Comments<br />
|}<br />
<br />
==Developer Tools==<br />
<br />
{| class="standard-table"<br />
|-<br />
!Title<br />
!Details - with links as appropriate<br />
!Reporter<br />
!Mentor(s)<br />
!Comments<br />
|-<br />
|'''Tilt'''<br />
|A WebGL-based 3D visualization of a Webpage. The developer will create a WebGL representation of a web-page that allows a user to rotate the page through axes to see the nesting of DOM nodes within the document. Floats and absolute positioned elements will be visible above and below the page based on their z-index. Tilt will be used as an additional visualization tool as part of a next-generation web page inspector.<br />
| Rob Campbell<br />
| Rob Campbell<br />
| Candidate must be proficient in JavaScript, DOM programming and have a good grasp of 3D graphics preferably some WebGL or OpenGL experience.<br />
|}<br />
<br />
==Drumbeat/Batucada==<br />
<br />
Any hacking projects connected to a [http://www.drumbeat.org/ Drumbeat] project or [https://wiki.mozilla.org/Drumbeat/Batucada Batucada].<br />
<br />
{| class="standard-table"<br />
|-<br />
!Title<br />
!Details - with links as appropriate<br />
!Reporter<br />
!Mentor(s)<br />
!Comments<br />
|}</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Tantek-Mozilla-Projects&diff=285341Tantek-Mozilla-Projects2011-02-17T00:50:32Z<p>Fantasai: /* CSS4 UI */</p>
<hr />
<div>Hi, I'm [[User:Tantek|Tantek Çelik]], and you've found my list of projects that I'm working on with Mozilla.<br />
<br />
I'm currently (as of 2010-146) a Mozilla contractor working with Chris Blizzard and the web [[standards]] team, focused on specification work, especially around web applications user interfaces and social/identity open web technologies. I participate in standards related [[events]] for both official organizations like W3C, and grass-roots efforts like microformats and ActivityStreams. If you have feedback for these groups, let me know!<br />
<br />
Specifications, efforts and summary status:<br />
* CSS<br />
** [[Tantek-Mozilla-projects#CSS_Style_Attributes|CSS Style Attributes]]: Achieved Candidate Recommendation (CR). Possible next steps, test cases/suite to help exit CR.<br />
** [[Tantek-Mozilla-projects#CSS3_Color|CSS3 Color]]: Achieved Proposed Recommendation (PR). Awaiting CSS 2.1 to reach PR.<br />
** [[Tantek-Mozilla-projects#CSS3_UI|CSS3 UI]]: editing CR toward producing a new LCWD.<br />
** [[Tantek-Mozilla-projects#UI_Layout|CSS UI Layout: Flex Box and Grid]]: Discussing differences and use cases with dbaron, and how to best design/define both for the benefit of web designers.<br />
** [[Tantek-Mozilla-projects#CSS3_Element|CSS3 Element]]: decide which draft to get it into (separate draft, Values and Units) and update draft accordingly.<br />
** [[Tantek-Mozilla-projects#CSS4_UI|CSS4 UI]]: collecting ideas, features, proposals towards writing a FPWD.<br />
** [[Tantek-Mozilla-projects#CSS4_Color|CSS4 Color]]: collecting ideas, features, proposals towards writing a FPWD.<br />
* [[Tantek-Mozilla-projects#HTML5_spec_improvements|HTML5]]: <br />
** follow-up on rejected/accepted spec improvement suggestions, figuring out next-steps for anything rejected<br />
** figure auto-close p issue. awaiting feedback from HTML5 Superfriends... then blog or email public-html about it.<br />
* [[Tantek-Mozilla-projects#DOM_API_vendor_prefixing|DOM API vendor prefixing]]: discussing internally at Mozilla to build consensus, set a good example.<br />
* [[vCard4]]: waiting-for responses to feedback on draft 15 to vcarddav group, updated draft (16?) with at least some of my requested changes being accepted.<br />
<br />
Unfiled:<br />
* Review http://dev.w3.org/csswg/css-module/Overview.src.html<br />
<br />
See below for more details on each.<br />
<br />
== Web Apps ==<br />
=== UI Styling ===<br />
At a high level there are two general clusters of use cases that web pages/apps want/need to solve in terms of user interface fidelity.<br />
<br />
'''1. Beautiful Built-in Tweakable Controls.''' Pages that have some interactivity where the designer wants to use the built-in set of semantic user interface controls/inputs as long as they can just "tweak" them to match their web page/site design, e.g. color, background, typography. As long as the look and feel of built-in controls is beautiful enough both by default and with minor tweaks, then the hypothesis is that web designers will be happy/content to use built-in controls rather than go the extra mile to re-build custom controls with divs and javascript etc.<br />
<br />
Some data for this hypothesis: default iPhone/iPad controls are pretty enough that most developers are more than happy to use them - the default controls make their apps look beautiful, polished, without much work/tweaking (modulo layout/sizing etc.) If we can achieve that same experience with built-in controls, the theory is that most web designers will be happy to stick with built-in controls + CSS.<br />
<br />
'''2. Rich native-app-like experiences.''' Games. Media interfaces like WinAmp. There are always going to be some user interfaces where the developer wants nearly total control of the look and feel. Just take a look at typical Flash or Flex app UIs (note: some of those are egregiously inconsistent with the underlying OS platform just for the sake of being different - hard to avoid that but we can discourage it by making the cluster 1 solution easier and more accessible). In this case I'd like to see us figure out how to build hybrid controls that:<br />
<br />
a) Are built with the closest semantic built-in control for any particular custom control, <em>and</em><br />
<br />
b) Use a &lt;canvas&gt; for drawing custom appearance, with DOM event handlers drawing control-specific state in the canvas, <em>and</em><br />
<br />
c) Have text-based fall-back in the canvas.<br />
<br />
Example markup (event attributes/handlers omitted for simplicity)<br />
<br />
<pre>&lt;button&gt;&lt;canvas&gt; Play &lt;/canvas&gt;&lt;/button&gt;</pre><br />
<br />
(Now we just need a way to do that with text inputs too.)<br />
<br />
The goal in this second scenario is to enable building rich native-app-like user interfaces where the path of least resistance to building it uses building blocks that in themselves enable accessibility. I think this is both possible, and is a necessary course of action to avoid having to do "bolt-on" accessibility later.<br />
<br />
<br />
For now, the sections below focus on addressing/solving the first cluster of use cases first.<br />
<br />
The theory is that by addressing that first that it will become more obvious which specific real-world rich interfaces fall into the second cluster, and therefore we can design for that second cluster based on those specific interfaces.<br />
<br />
==== Styling HTML5 UI elements ====<br />
We need to define how Forms and other UI elements can be styled, and to synchronize our work with the W3C.<br />
<br />
Working with Mounir Lamouri on this: [[User:Mounir.lamouri/HTML5_Forms]]<br />
<br />
Each [[HTML5]] UI element must be complete to the following criteria:<br />
<br />
1. It must include pleasant and working UI, where appropriate.<br />
<br />
This is a big design challenge. Take a look at what Opera has done for example (in terms of challenges). Here is a simple test page which shows default renderings - compare in various browsers and try interacting with the new widgets especially in Opera:<br />
<br />
http://tantek.com/new-inputs.html<br />
<br />
See [[HTML5/input]] for more &lt;input&gt; element tests.<br />
<br />
* Need more sample/test/wiki pages for other HTML5 UI elements.<br />
<br />
2. You must be able to use CSS to style the element, especially the UI that we generate. This includes any pre-defined pseudo-selectors (invalid, required, icon, etc.)<br />
<br />
Agreed, this is an absolute requirement.<br />
<br />
Whenever there is ''any'' custom appearance of a form control, e.g. based on the new types, designers ''must'' be able to restyle them to fit in with their design. This means at a minimum:<br />
* ability to select specific "pieces" of any compound/composite form control for styling<br />
** feeds into requirements for CSS pseudo-elements<br />
** consider existing [http://www.w3.org/TR/css3-ui/#pseudo-elements CSS3-UI pseudo-elements]<br />
*** ::value can be used for selecting/styling placeholder text (see [https://bugzilla.mozilla.org/show_bug.cgi?id=457801#c25 bug 457801 comment 25])<br />
*** ::choices <br />
*** ::repeat-item <br />
*** ::repeat-index<br />
** consider additional pseudo-elements based on vendor prefixed pseudos<br />
*** Safari 5 supports pseudo-elements for restyling overflow scrollbars<br />
**** ::webkit-scrollbar-thumb<br />
**** ::webkit-scrollbar-track<br />
**** ::webkit-scrollbar<br />
* ability to select specific "states" of any form control (may require ability to select states of specific pieces as well - that will be a challenge though as pseudo-elements themselves cannot have pseudo-classes in CSS)<br />
** existing [http://www.w3.org/TR/css3-selectors/#UIstates Selectors UI pseudo-classes], and some notes on [http://www.w3.org/TR/html5/interactive-elements.html#pseudo-classes how HTML5 DOM property states trigger these pseudo-classes]<br />
*** :hover :active - based on mouse/pointer interactions. the challenge here is to find alternatives for touch based interfaces.<br />
*** :focus - an element which is currently accepting keyboard, pointer, or other input device events.<br />
*** :enabled and :disabled - based on the state of the "disabled" property on the element.<br />
*** :checked - based on the "checked" property on input types "radio" and "checkbox", and also on the "selected" property on option element.<br />
*** :indeterminate - based on the "indeterminate" property of the input types "radio" and "checkbox".<br />
*** :default - [http://www.w3.org/TR/html5/interactive-elements.html#selector-default default buttons or submit buttons]<br />
*** :valid and :invalid - input elements that are candidates for constraint validation and either do or don't (respectively) satisfy their constraints.<br />
*** :in-range and :out-of-range - input elements that are candidates for constraint validation and that are neither under nor overflowing (for :in-range) or either under/overflowing (for :out-of-range).<br />
*** :required and :optional - [http://www.w3.org/TR/html5/interactive-elements.html#selector-required see HTML5 description of being required / required attribute]<br />
*** :read-only and :read-write - [http://www.w3.org/TR/html5/interactive-elements.html#selector-read-only see HTML5 description of read-only vs read-write elements].<br />
** additional pseudo-selectors as needed for states/portions included in HTML5 forms elements features<br />
*** "placeholder" attribute - needs a new :-moz-placeholder pseudo-class ([https://bugzilla.mozilla.org/show_bug.cgi?id=457801 bug 457801])<br />
**** :placeholder pseudo-class needs to be proposed for CSS3.1 UI/Selectors.<br />
* typography<br />
** font properties<br />
** text properties<br />
** color<br />
* box properties<br />
** width<br />
** height<br />
** padding<br />
** border<br />
** margin<br />
** background<br />
** box-shadow<br />
<br />
<br />
3. If there's a constraint API the API must be complete.<br />
<br />
4. It should be [[Accessibility/HTML5_Forms|fully accessible]].<br />
<br />
==== Possible new HTML5 UI elements ====<br />
The new user interface elements in HTML5 cover quite a bit of Web Apps UI scenarios. There are both requests based on specific user/application scenarios, and there is also the full set of user interface objects represented by the values of the CSS3 UI 'appearance' property<br />
===== specific new elements =====<br />
* <code>&lt;menubar&gt;</code><br />
* pull-down-menu<br />
* context-menu<br />
* <code>&lt;input type="year"&gt;</code> - based on <code>&lt;time&gt;</code> element use case research<br />
* <code>&lt;input type="month-day"&gt;</code> - based on <code>&lt;time&gt;</code> element use case research<br />
<br />
===== CSS3 UI appearance values =====<br />
From [http://www.w3.org/TR/css3-ui/#appearance-val CSS3 UI 5.1. Appearance values]:<br />
<br />
Needs:<br />
* tab - a button that looks like the browser's tabbed windows tabs.<br />
* menubar - a menu of menus, typically arranged linearly, in a horizontal bar. <br />
* pull-down-menu - a menu where the name of the menu is displayed and the options remain hidden until the user activates the menu. When the user releases or deactivates the menu, the options are hidden again.<br />
* radio-group - a menu where the options are displayed as radio-buttons.<br />
* checkbox-group - a menu where the options are displayed as checkboxes. <br />
* outline-tree - a menu where the options can be shown or hidden with small widgets, often represented by a small triangle or plus and minus signs. might be possible to build one using <code>&lt;details&gt;</code> and <code>&lt;summary&gt;</code>.<br />
* combo-box - a field which is accompanied by a menu of preset values that can be used to quickly enter common or typical values. <br />
* signature - a field for entering a signature. <br />
<br />
Full list with equivalents:<br />
* icon - handled by 'icon' property and HTML5 Drag &amp; Drop<br />
* window - mostly handled outside of elements, except perhaps 'tooltip' which could be purely presentational<br />
* button - by default a push-button<br />
** push-button - <code>&lt;input type=button&gt;<code> and <code>&lt;button&gt;</code><br />
** hyperlink - <code>&lt;a href&gt;</code><br />
** radio-button - <code>&lt;input type="radio"&gt;</code><br />
** checkbox - <code>&lt;input type="checkbox"&gt;</code><br />
** menu-item - <code>&lt;option&gt;</code> and <code>&lt;optgroup&gt;</code><br />
** tab - no HTML5 equivalent<br />
* menu - by default a pop-up-menu<br />
** menubar - no HTML5 equivalent<br />
** pull-down-menu - no HTML5 equivalent<br />
** pop-up-menu - <code>&lt;select&gt;</code><br />
** list-menu - <code>&lt;select size=n</code> (where n>1)<br />
** radio-group - no HTML5 equivalent<br />
** checkbox-group - no HTML5 equivalent<br />
** outline-tree - no complete HTML5 equivalent but <code>&lt;details&gt;</code> and <code>&lt;summary&gt;</code> may help.<br />
** range - <code>&lt;input type="range"&gt;</code><br />
* field - <code>&lt;input type="text"&gt;</code> and <code>&lt;textarea&gt;</code><br />
** combo-box - no HTML5 equivalent<br />
** signature - no HTML5 equivalent<br />
** password - <code>&lt;input type="password"&gt;</code><br />
<br />
==== CSS Style Attributes ====<br />
;latest published draft (CR)<br />
:http://www.w3.org/TR/css-style-attr/<br />
;latest development / in progress draft<br />
:http://dev.w3.org/csswg/css-style-attr/<br />
;spec source (for editing)<br />
:http://dev.w3.org/csswg/css-style-attr/Overview.src.html<br />
;test suite<br />
:TBD<br />
;implementation reports of the test suite<br />
:TBD<br />
;issues list for the current draft<br />
:http://wiki.csswg.org/spec/css-style-attr<br />
<br />
===== remaining tasks =====<br />
* email Hixie to update reference to CSS Style Attributes draft in [http://www.whatwg.org/specs/web-apps/current-work/multipage/references.html#references HTML5 References]<br />
<br />
See also CSSWG wiki task list: http://wiki.csswg.org/spec/css-style-attr<br />
<br />
==== CSS3 UI ====<br />
;latest published draft<br />
:http://www.w3.org/TR/css3-ui/<br />
;latest development / in progress draft<br />
:http://dev.w3.org/csswg/css3-ui/<br />
;spec source (for editing)<br />
:http://dev.w3.org/csswg/css3-ui/Overview.src.html<br />
;test suite<br />
:TBD<br />
;implementation reports of the test suite<br />
:TBD<br />
;issues list for the current draft<br />
:http://wiki.csswg.org/spec/css3-ui<br />
<br />
===== remaining tasks =====<br />
Remaining tasks to get CSS3 UI to PR:<br />
<br />
* '''text-overflow'''<br />
** clarify text per emails from fantasai/RoC or consider explicitly stating as undefined (per suggestions from RoC)<br />
*** the behavior of text-overflow:ellipsis on a block with 'overflow' of 'scroll' (no good interop, ideal behavior documented, needs screenshots)<br />
**** testcase from RoC: http://lists.w3.org/Archives/Public/www-style/2011Jan/att-0669/test.html<br />
*** interaction of text-overflow:ellipsis with event handling<br />
*** behavior of text-overflow:ellipsis on lines containing replaced elements<br />
** also create an implementer FAQ on the CSS WG wiki re: text-overflow accordingly<br />
* '''resolve issues'''. resolve/apply proposals from issues list: http://wiki.csswg.org/spec/css3-ui <br />
* '''overflow-x overflow-y'''. consider incorporating '''[https://developer.mozilla.org/En/CSS/Overflow-x overflow-x]''' and '''[https://developer.mozilla.org/En/CSS/Overflow-y overflow-y]'''<br />
** pull-in the entirety of section 16 from<br />
*** http://www.w3.org/Style/Group/css3-src/css3-box/#overflow<br />
** sync (incorporated) any updates/changes in 2.1:<br />
*** http://www.w3.org/Style/Group/css2-src/visufx.html#overflow<br />
** search www-style for issues related to 'overflow-x' and 'overflow-y'<br />
*** ask Anne van Kesteren and www-style directly<br />
** check that css3-marquee implicitly deals with overflow-x and overflow-y correctly<br />
*** http://www.w3.org/TR/css3-marquee/#the-overflow-style<br />
** investigate discussion of ink overflow vs layout overflow - [[User:Fantasai|fantasai]] will get more info on this. e.g. box-shadow should never trigger scrollbars. do margins? maybe they don't trigger overflow but if there is overflow anyways (something else triggers scrollbars), then margins influence the dimensions of the scrollable area.<br />
<br />
* '''implementation documentation'''. document claims of existing implementations (CSSWG implementers have until 2010-09-17 to submit claims of implementation)<br />
** Webkit CSS3 UI - http://lists.w3.org/Archives/Public/public-html/2009Sep/0060.html<br />
** Opera CSS3 UI - http://lists.w3.org/Archives/Public/public-html/2009Sep/0202.html<br />
** Mozilla CSS3 UI<br />
*** [https://developer.mozilla.org/en/CSS/:default :default]<br />
*** [https://developer.mozilla.org/En/CSS/:indeterminate :indeterminate]<br />
*** [https://developer.mozilla.org/En/CSS/::selection ::-moz-selection] - needs removal of prefix.<br />
*** [https://developer.mozilla.org/en/CSS/:-moz-placeholder :-moz-placeholder]<br />
*** more UI related pseudo-classes discussed in [https://developer.mozilla.org/en/CSS_Reference#Pseudo-classes devmo CSS Reference]<br />
*** [https://developer.mozilla.org/en/CSS/-moz-appearance -moz-appearance] - needs analysis to figure out if it complies with intent of 'appearance' property<br />
*** [https://developer.mozilla.org/En/CSS/Box-sizing -moz-box-sizing] - needs unprefixing ([https://bugzilla.mozilla.org/show_bug.cgi?id=243412 bug 243412]). <br />
**** extra value 'padding-box' is implemented - consider adding it to CSS3-UI<br />
*** 'cursor' - new values<br />
**** [https://developer.mozilla.org/en/CSS/-moz-alias alias] - verify works w/o prefix.<br />
**** [https://developer.mozilla.org/en/CSS/-moz-cell cell] - verify works w/o prefix.<br />
**** [https://developer.mozilla.org/en/CSS/-moz-copy copy] - verify works w/o prefix.<br />
*** [https://developer.mozilla.org/en/CSS/outline-offset outline-offset] - <br />
** Internet Explorer 8 CSS3 UI support - ??? (expect email from johnjan @ MS)<br />
** IE5/Mac CSS3 UI support - ???<br />
<br />
* draft and publish at least a minimal coverage test suite that covers those claims<br />
<br />
* document actual implementation results<br />
<br />
* reducing feature set down to what's been implemented in more than one browser<br />
** write new CSS3 UI LCWD editors draft with only non-at-risk features based on above implementation evidence (or imminent implementation - kept at risk)<br />
** write new UI Selectors FPWD editors draft with all new UI selectors (consider limiting to those with at least one implementation, any with less than 2 implementations, mark at risk up front)<br />
* collect/address new CSS3 UI LCWD issues as they are reported<br />
** respond to all the commenters on issues with proposed resolutions (hopefully thus addressing their concerns and resolving the issues accordingly)<br />
** incrementally draft new CSS3-UI CR draft accordingly<br />
<br />
* wait for new CSS3 UI LCWD last-call period to end<br />
<br />
* write UI Selectors LCWD - with features with at least one implementation, any with less than 2 implementations, mark at risk.<br />
<br />
* edit CSS3-UI CR draft accordingly that is ready for PR<br />
<br />
* WG processes for taking it to PR<br />
<br />
Remaining related Firefox bugs/development tasks (stub/incomplete)<br />
For each of these, figure out who is the right Mozilla developer to work on this and then work with to understand what it will take to get it implemented:<br />
* cursor / border-radius interaction bug: [https://bugzilla.mozilla.org/show_bug.cgi?id=595652 595652]<br />
** if/when fixed, add that detail to spec<br />
* cursor on root element applying to viewport: [https://bugzilla.mozilla.org/show_bug.cgi?id=568450 568450] <br />
** if/when fixed, add that detail to spec<br />
* icon support: http://www.w3.org/TR/css3-ui/#element<br />
** 'icon' property<br />
** 'content:icon' value<br />
* box-sizing prefix drop: https://bugzilla.mozilla.org/show_bug.cgi?id=243412<br />
* ...<br />
<br />
Additional CSS3 UI related features in Mozilla to investigate:<br />
* [https://developer.mozilla.org/en/CSS/-moz-user-focus -moz-user-focus]<br />
<br />
==== CSS4 UI ====<br />
* write CSS4 UI FPWD with:<br />
** previous CSS3-UI features that got dropped<br />
*** stuff from CSS3 UI CR that only had one implementation (that we believe is worthy of standardizing, or at least one other implementer expresses interest on)<br />
*** stuff from and related to previous CSS3 UI drafts that's been reraised<br />
**** 'user-input'<br />
**** 'user-focus'<br />
**** 'user-modify'<br />
**** 'user-select'<br />
***** all suggested to replace 'contentEditable': [http://lists.w3.org/Archives/Public/www-style/2010Dec/0371.html www-style: Implementing contentEditable in CSS3 UI]<br />
** other CSS features that are UI related in other CSS or other W3C specs<br />
*** :placeholder pseudo-class. related: [https://bugzilla.mozilla.org/show_bug.cgi?id=457801 bug 457801]<br />
*** '''overflow-radius''' per implementation: Mozilla supports [https://developer.mozilla.org/en/CSS/-moz-outline-radius -moz-outline-radius] (no second implementation however - thus in CSS4 UI)<br />
*** CSS3 Hyperlink<br />
*** text-overflow:&lt;string&gt;. consider incorporating dropped &lt;string&gt; value. Here are the markup changes for that: <br />
<pre><nowiki><br />
<td>clip | ellipsis | <br />
<a class="noxref" href="http://www.w3.org/TR/CSS21/syndata.html#value-def-string"><br />
<span class="value-inst-string">&lt;string&gt;</span></a><br />
</td><br />
...<br />
<dt><dfn title="text-overflow:&lt;string&gt;"><br />
<code><var>&lt;string&gt;</var></code></dfn></dt><br />
<dd>Render the given string to represent clipped text.</dd><br />
</nowiki></pre><br />
*** [[HTML5]] inputs/forms features that are presentation related<br />
** new features<br />
*** CSS portions of [[Gecko:FullScreenAPI]], e.g. the new pseudo-classes<br />
*** <span id="new-resize-values">new 'resize' values</span> - e.g. '''grow-vertical''', '''grow-horizontal'''<br />
**** Facebook uses some JS to add rows to text areas when you hit the end of the available space. It feels nicer than a scrollbar because you can see all of what you typed -- the height of the text area just grows and grows as you need it. It would be great to have 'resize' property values that allow the browser to auto-grow a textarea as a user enters data, e.g. 'grow-horizontal', 'grow-vertical'. 'grow-vertical' would emulate the current behavior that FB does with JS. (note from fantasai - this is the behavior you'd get with fixed min-height and auto height, so CSS can do this already if HTML doesn't get in the way)<br />
**** Update 2011-032: [http://twitter.com/LeaVerou/status/32642516146724866 @LeaVerou requested] "elastic textarea effect with pure CSS" [http://twitter.com/LeaVerou/status/32651575688175616 and follow-up]: "mostly about height, not width" which sounds like resize:grow-vertical. There's also mention of "-moz-available" (need to research that and link it up).<br />
** forward reaching properties/values to enable native-like interfaces<br />
*** 'spell-check'<br />
*** 'grammar-check'<br />
**** both suggested by: [http://lists.w3.org/Archives/Public/www-style/2010Dec/0383.html www-style: Re: Implementing contentEditable in CSS3 UI]<br />
*** more "overflow" extensions: http://wiki.csswg.org/spec/css3-overflow<br />
<br />
==== CSS3 Element ====<br />
===== write up moz-element proposal =====<br />
Firefox 4 implements background: -moz-element(#foo); to use element with id foo as the background per http://hacks.mozilla.org/2010/08/mozelement/ <br />
<br />
We're pursuing adding element(#foo) as an "at-risk" feature to the CSS3 Values and Units module.<br />
<br />
Proposal (worked with Tab Atkins)<br />
* http://lists.w3.org/Archives/Public/www-style/2010Aug/0635.html<br />
<br />
Threads:<br />
* [http://lists.w3.org/Archives/Public/www-style/2010Aug/thread.html#msg635 element() 2010-08]<br />
* [http://lists.w3.org/Archives/Public/www-style/2010Sep/thread.html#msg0 element() 2010-09]<br />
<br />
Thoughts:<br />
* CSS image() value - which Tab Atkins is already writing up<br />
* Add both to CSS3 Values and Units as at risk for taking it quickly to CR<br />
** in addition to the calc() work that David Baron is already doing in CSS3 Values and Units<br />
<br />
==== CSS4 Color ====<br />
* collect new features for CSS3.1/4 Color - color-correction<br />
** follow-up on color management properties for css3-color that were discussed at 2009 November TPAC CSS f2f (but later punted from css3-color to a future version).<br />
*** check minutes from that meeting for details on conclusions of the property (name, values etc.)<br />
*** contact Beth regarding level of implementation interest, plan to move forward with putting the color management property into a post-css3 working draft of the Color Module<br />
* write a first working draft of CSS3.1/4 Color with collected feature(s) (even if it includes just a new color management property)<br />
* find out where Hixie's tests went (was at http://test.csswg.org/source/contributors/hixie/incoming/css3-color/ ) and figure out what to do with them.<br />
<br />
=== DOM API vendor prefixing ===<br />
==== spec implementation problem statement ====<br />
Problem statement: the '''specification-implementation co-dependency problem'''.<br />
<br />
All standards in development have the challenging seemingly contradictory problems of:<br />
# '''needing some implementation to reality-check''' that the API/protocol/format "works" as intended, or is workable/usable<br />
# '''being stuck with a specific (often buggy) implementation''' once it ships because there's content/pages/apps out there that depend on it.<br />
<br />
There are three areas of the open web app platform that this has been problematic:<br />
# '''CSS'''. In the past, some properties were implemented, either as spec'd (and the spec was buggy), or in a way that made sense but incompatible with the spec (because the spec didn't make sense or was not useful to web authors), and then we got "stuck" with those implementations and were not able to update/fix the spec and the respective properties and/or values. Examples:<br />
## 'clip' property. mis-specified in CSS 2.0. implemented as presumed intended in IE4/Windows etc. but turned out to be buggy. some content started depending on it. we (CSS WG at the time) were unable to really fix it in a way that implementations could change, though [http://www.w3.org/TR/CSS21/visufx.html#clipping CSS 2.1 tries to fix clip].<br />
## 'word-wrap' property. in this case, created/proposed by Microsoft, and [http://msdn.microsoft.com/en-us/library/ms531186.aspx implemented as of IE5.5/Windows ca 2000], we are again, kind of stuck with the particular implementation. [http://www.codingforums.com/archive/index.php/t-2075.html Forum posts as of 2002 were recommending use of the literal word-wrap property]. Though since Microsoft did switch to advocating/supporting a prefixed version '-ms-word-wrap'. Note that it is also [https://developer.mozilla.org/en/CSS/word-wrap supported in Firefox 3.5 ca 2009], and it is in the latest (2007) version of the [http://www.w3.org/TR/2007/WD-css3-text-20070306/#word-wrap CSS3 Text spec which is just a working draft].<br />
### See related 'word-break' property ([http://www.w3.org/TR/2007/WD-css3-text-20070306/#word-break word-break in CSS3 Text WD] - latest, 2007), also [http://msdn.microsoft.com/en-us/library/ms531184.aspx initially (partially) implemented in Internet Explorer 5.x as word-break], and later switched to the prefixed '-ms-word-break'. [http://msdn.microsoft.com/en-us/library/cc351024%28VS.85%29.aspx More on CSS Compatibility and Internet Explorer].<br />
# '''HTML'''. Too many examples to list here. Some browsers are still stuck supporting <code>&lt;blink&gt;</code> and <code>&lt;marquee&gt;</code> (which has many odd details), nevermind the classic example of <code>&lt;table&gt;</code> layout, with tons of odd special cases and error-handling for compat, originally from Netscape's implementation, reverse-engineered by Microsoft in Internet Explorer, which has subsequently been reverse-engineered by every other browser.<br />
# '''DOM'''. In particular [http://www.w3.org/TR/2009/WD-webstorage-20091222/ Web Storage working draft] (e.g. the 'localStorage' attribute/property) was implemented in multiple browsers (IE8+, Chrome, Safari, Opera, Mozilla as of 2010 - date order unknown). By the time people discovered it was not threadsafe as specified, it was too late to change the spec to fix that problem - it would have broken too many apps/sites already written which apparently depended on it.<br />
<br />
==== existing solutions ====<br />
<br />
The only one of these areas of technology that has an explicit solution to the specification-implementation co-dependency problem is CSS, through vendor-prefixes.<br />
<br />
===== CSS vendor prefixes =====<br />
In the early 2000s the participants in the CSS working group agreed to formalize a way for implementors to build experimental implementations of new properties and values which were only in a working draft (not yet in a Candidate Recommendation) without saddling the property with implementation specific bugs that content would end up inadvertently depending on.<br />
<br />
CSS prefixing is fairly straight forward:<br />
<br />
<pre>- abbreviated_vendor_prefix - property_name</pre><br />
<br />
(spaces added for clarification of the different components)<br />
<br />
Examples include:<br />
* -moz-opacity<br />
* -o-border-radius<br />
* -webkit-border-radius<br />
* -ms-word-wrap<br />
<br />
===== CSS vendor prefixes case studies =====<br />
* '''border-radius'''. for a few years now browsers have been implementing ''vendor prefixed'' versions of the border-radius properties, web authors have been experimenting on the web, and the spec has iterated/improved based on feedback. Now we have a well-designed and road-tested 'border-radius' property in a CR spec and implementations are implementing that.<br />
* '''word-wrap vs whitespace: pre-wrap'''. interactions between new properties and new values on existing properties. See this [http://scottonwriting.net/sowBlog/archive/0000/00/00/163005.aspx example of the property vs value interaction] between the new 'word-wrap' property and the (sometimes prefixed) new 'pre-wrap' value on the 'whitespace' property. The point is to show how prefixing can actually work across different approaches to evolving CSS.<br />
<br />
===== CSS vendor prefixes successes =====<br />
Several well known web designers and developers have written at length about the successes of CSS vendor prefixes, and how they have both helped avoid problems from before, and actually improve the evolution of CSS.<br />
<br />
* [http://www.alistapart.com/articles/prefix-or-posthack/ A List Apart: Prefix or Posthack] by Eric Meyer<br />
* [http://www.webmonkey.com/2010/07/advice-from-the-css-guru-embrace-prefixes/ WIRED Webmonkey: Advice From the CSS Guru: Embrace Prefixes] by By Michael Calore<br />
* [http://www.the-haystack.com/2010/03/22/coping-with-css-prefixes/ The Haystack: Coping with CSS vendor prefixes] by Stephen Hay<br />
* [http://snook.ca/archives/html_and_css/not-supported Snook.ca: NOT SUPPORTED] by Jonathan Snook<br />
* [http://annevankesteren.nl/2010/03/css-vendor-prefix Anne van Kesteren: In defense of CSS prefixes] by Anne van Kesteren<br />
<br />
==== analysis of applicability ====<br />
Can we apply similar thinking and solutions to HTML and/or DOM?<br />
<br />
For HTML (or any markup) the thinking is no - because of the fact that an element only allows one tagname, there is no way to have content first use a vendor prefixed tagname (or tagnames from multiple vendors), and then also use a final unprefixed tagname all at the same time as part of a content evolution/transition strategy. CSS vendor prefixing works (as illustrated in the case studies) because authors ''can'' create style sheets that use multiple versions of a property (vendor prefixed and unprefixed) in one style sheet, together while evolving their content over time.<br />
<br />
For DOM, it is not only possible, but there are examples in the wild.<br />
<br />
[https://developer.mozilla.org/en/DOM/window.onmozorientation mozOrientation] is a good example of a vendor prefixed DOM interface implementation. (Note mozOrientation needs to be submitted to a W3C working group for standardization/iteration)<br />
<br />
==== simple DOM vendor prefixes proposal ====<br />
<br />
For all DOM interfaces that are:<br />
* Proprietary. No standards organization draft yet published. OR<br />
* In a W3C working draft, not yet in a Candidate Recommendation.<br />
<br />
Use vendor prefixed interfaces and values as follows:<br />
<br />
<pre>vendor_prefix _ unprefixed_name</pre><br />
<br />
E.g. in the above example of mozOrientation, we really should be using:<br />
<br />
<pre>moz_Orientation</pre><br />
<br />
This works because standard DOM APIs do not use underscores.<br />
<br />
Our goal is to establish a convention (like the above) for all such pre-CR DOM APIs that has the consensus of implementers so that we can avoid creating broken versions of APIs<br />
<br />
==== simple protocol scheme prefixes proposal ====<br />
The WebSockets specification (and iteration) provides a good example of a W3C Working Draft that has work also going on at the IETF (perhaps primarily), and there is a high likelihood of backwards incompatible changes being made to WebSockets's "ws:" protocol between different versions (-76, -00, -01).<br />
<br />
Thus it is worth considering prefixing implementations of the "ws:" protocol in order to break/rev as necessary instead of being locked into a specific draft due to premature reliant adoption.<br />
<br />
For all protocol schemes that are:<br />
* Proprietary. No standards organization draft yet published. OR<br />
* In a W3C or IETF working draft, not yet in a Candidate Recommendation, or perhaps public last call for IETF drafts (open to suggestions here).<br />
<br />
Use vendor prefixed protocol schemes as follows:<br />
<br />
<pre>vendor_prefix - unprefixed_name</pre><br />
<br />
E.g. WebSockets has a new ws: scheme, and we've implemented it in Firefox 4. We really should be using:<br />
<br />
<pre>moz-ws:</pre><br />
<br />
Our goal is to establish a convention (like the above) for all such pre-CR protocol schemes that has the consensus of implementers so that we can avoid creating broken versions of protocols.<br />
<br />
<br />
==== simple HTML attributes prefixes proposal ====<br />
Implementing prefixes on element names doesn't work because you can't have more than one element name per element, and thus prefixed versions would force developers to choose between unprefixed and a particular prefixed version.<br />
<br />
However elements do have multiple attributes, and thus prefixing can work for attributes.<br />
<br />
For all HTML attributes that are:<br />
* Proprietary. No standards organization draft yet published. OR<br />
* In a W3C working draft (e.g. New in HTML5), not yet in a Candidate Recommendation.<br />
<br />
Use vendor prefixed attributes as follows:<br />
<br />
<pre>vendor_prefix _ unprefixed_name</pre><br />
<br />
E.g. HTML5 has a new [http://www.w3.org/TR/html5/common-input-element-attributes.html#attr-input-pattern 'pattern' attribute], and we've implemented it in Firefox 4. We really should be using:<br />
<br />
<pre>moz_pattern</pre><br />
<br />
This works because standard HTML attributes do not use underscores.<br />
<br />
Our goal is to establish a convention (like the above) for all such pre-CR new HTML5 attributes that has the consensus of implementers so that we can avoid creating broken versions of elements.<br />
<br />
=== UI Layout ===<br />
CSS3 Flex Box and Grid<br />
<br />
There are two new CSS3 layout mechanisms being developed that could greatly assist with the layout of user interfaces.<br />
<br />
* CSS3 Flex Box<br />
** current working draft: http://www.w3.org/TR/css3-flexbox/<br />
** current editor's draft: http://dev.w3.org/csswg/css3-flexbox/ <br />
** Tab's proposed update: http://dev.w3.org/csswg/css3-flexbox/Overview.new.src.html<br />
** Tab's documentation of differences between editor's draft and his draft: http://www.xanthir.com/blog/b48Z0<br />
<br />
* CSS3 Grid<br />
** 2007-09-05 (current) working draft: http://www.w3.org/TR/css3-grid/<br />
** 2008-01-06 (current) editor's draft: http://dev.w3.org/csswg/css3-grid/<br />
<br />
* CSS3 Grid Align - not clear on the relation between Grid and Grid Align<br />
** Alex Mogilevsky's CSS3 Grid Align first draft: http://www.interoperabilitybridges.com/css3-grid-align/<br />
*** Alex's www-style email thread announcing his draft: http://lists.w3.org/Archives/Public/www-style/2010Oct/thread.html#msg787<br />
** 2010-11-18 (current) editor's draft: http://dev.w3.org/csswg/css3-grid-align/<br />
<br />
Some next-steps:<br />
* need to get in touch with Tab Atkins and catch-up on the current state of his Flex Box work vs. existing prefixed partial implementation in Firefox and Safari.<br />
** 2010-155 briefly spoke with Tab about flex box in irc and noted that I'm working on css3-color and css3-ui first.<br />
<br />
=== HTML5 spec improvements ===<br />
A set of tasks/projects for improving the state of the [[HTML5]] specification. Proposals will be moved to separate pages once mature enough for submission to [[standards]] bodies.<br />
<br />
Most of this has been moved to [[HTML5#spec_issues|HTML5: spec issues]].<br />
<br />
Next: follow-up on each, determining next steps on rejected proposals.<br />
<br />
==== waiting for HTML5 improvements ====<br />
==== keeping crappy stuff out ====<br />
===== simplify alt attribute guidance =====<br />
Moved to [[HTML5/img#alt_guidance_needs_simplification|HTML5/img]].<br />
===== remove meta Content-Language =====<br />
Moved to [[HTML5/meta#remove_meta_Content-Language|HTML5/meta]]<br />
==== upgrade HTML4 features to be more flexible and usable ====<br />
==== restoring pragmatic HTML4 things ====<br />
Moved to [[HTML5/cite#names_of_speakers|HTML5/cite]].<br />
==== improving new features ====<br />
===== iframe sandbox removal =====<br />
Moved to [[HTML5/iframe#drop_sandbox_attribute|HTML5/iframe]].<br />
===== summary naming =====<br />
Moved to [[HTML5/summary#summary_naming|HTML5/summary]]<br />
===== expand time =====<br />
Moved to [[HTML5/time#expand_time|HTML5/time]]<br />
===== nesting time =====<br />
Moved to [[HTML5/time#nesting_time|HTML5/time]]. am pm handling too.<br />
<br />
==== lower priority improvements ====<br />
* <code>&lt;meter&gt;</code> - poorly named. would prefer something like "gauge" but that's potentially hard(er) to spell. this is a bit bikesheddy though so not a high priority.<br />
<br />
<br />
== Web Apps Waiting For ==<br />
Tasks which are awaiting follow-ups from various standards bodies/lists. Reping as necessary to keep moving forward.<br />
<br />
=== CSS Waiting For ===<br />
==== CSS3 Backgrounds and Borders ====<br />
Waiting for CR of http://www.w3.org/TR/css3-background/<br />
<br />
And then: outstanding UI related issues:<br />
<br />
===== prefix removal from -moz-border-radius =====<br />
<br />
Currently Mozilla's border-radius properties are prefixed with -moz- and the following bugs/issues are preventing us from removing the prefix:<br />
<br />
* '''% values on border-radius.''' There is existing content (themes?) that depend on the legacy moz-border-radius implementation of % values that depend on the % of *width* in both dimensions.<br />
<br />
* '''clipping overflow and replaced elements.''' We don't currently clip overflow hidden and replaced elements (e.g. img, video, canvas) to rounded corners. We need to do to this for a proper/complete implementation that won't risk creating further legacy/backward compat problems.<br />
<br />
Bugzilla bugs:<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=431176 431176] - (border-radius) Tracking bug for remaining issues with CSS3 border-radius<br />
*[https://bugzilla.mozilla.org/show_bug.cgi?id=451134 451134] - change -moz-border-radius* properties to css3-background names<br />
<br />
== Social and Identity ==<br />
=== Related Features ===<br />
Features/people working with:<br />
* [[Account Manager]] - Dan Mills<br />
* Mozilla Contacts - Michael Hanson<br />
* Context Menu - Aza Raskin<br />
** see related: 2010-05-03 [http://mozillalabs.com/jetpack/2010/05/03/context-menu-module-microformats/ The Context Menu Module & Microformats] (JetPack)<br />
* ...<br />
<br />
=== Standards and Communities ===<br />
Standards and communities to engage with (recommended, grouped by related)<br />
<br />
identity / profiles / contacts<br />
* [[vCard4]] (IETF vcarddav)<br />
** write up problems with vCard4, divergence from vCard3/hCard/PoCo model, etc.<br />
* [[hCard]] (microformats.org)<br />
* Portable Contacts<br />
* microdata vcard vocab (W3C/WhatWG)<br />
* RelMeAuth<br />
* OpenID<br />
* WebFinger<br />
* ...<br />
<br />
social web<br />
* OAuth (including OAuth 2, xAuth, OWF)<br />
* Activity Streams<br />
* [http://federatedsocialweb.net/ Federated Social Web]<br />
* ...<br />
<br />
== Events ==<br />
[[Events]] I'm planning on participating in accordingly:<br />
* September 23-25 [http://north10.webdirections.org/ Web Directions USA in Atlanta]<br />
<br />
== Web Standards Coordination ==<br />
There are a lot of people at Mozilla working with a variety of different standards bodies. With Arun's recent departure, it's more clear than ever that we need to at least have some sort of a directory of standards organizations (and sub-orgs like working groups) listing who at Mozilla is working with each.<br />
<br />
* [[Standards]] - who is working on what standards in what organizations<br />
<br />
== Reference ==<br />
=== Pages ===<br />
See [[User:Tantek#pages|reference pages created]]<br />
<br />
=== Done ===<br />
Completed tasks, projects, events that have no further related active work items. Will likely move to its own page as it grows, in which case, I'll probably just keep *recently* finished items here and regularly archive them.<br />
<br />
==== Completed Events ====<br />
* June 1-3 Open Source Bridge, Portland, OR, http://opensourcebridge.org<br />
* June 28-30 Voices That Matter Web Design in SF http://www.voicesthatmatter.com/webdesign2010<br />
<br />
* July 6-10 [[Summit2010|Mozilla Summit]] in Whistler, Canada.<br />
* July 13 [http://www.realestateconnect.com/program/ Real Estate Connect San Francisco] (click on "Workshops »", search for "HTML5") at Hilton San Francisco Union Square, 333 O'Farrell Street, San Francisco, California<br />
** participating in WORKSHOP: ConnectTech / HTML5 Is Coming, Are You Ready?<br />
* July 17 [http://openwebcamp.org OpenWebCamp II] at Stanford<br />
* July 18 [http://federatedsocialweb.net/wiki/Main_Page Federated social web summit] ([http://federatedsocialweb.net/wiki/Schedule schedule])<br />
** more info: [http://status.net/2010/06/28/federated-social-web-summit-2010-announced announcement], [http://federatedsocialweb.net/wiki/FedAll2010/Invitations attendees]<br />
<br />
* August 23-25 [http://www.w3.org/Style/Group/2010/Oslo W3C CSS WG f2f in Oslo]<br />
<br />
* September 1-3 [http://2010.dConstruct.org/ dConstruct in Brighton] - web design and development<br />
<br />
==== Resolved HTML5 improvements and spec issues ====<br />
===== reject longdesc =====<br />
moved to: [[HTML5/img#reject_longdesc|HTML5/img]]<br />
===== allow date only on del ins datetime attribute =====<br />
* moved to [[HTML5/del#datetime_should_take_date|HTML5/del]].<br />
<br />
==== CSS ====<br />
===== CSS Style Attributes =====<br />
* CSS Style Attributes - achieved CR!<br />
;latest published draft (CR)<br />
:http://www.w3.org/TR/css-style-attr/<br />
;latest development / in progress draft<br />
:http://dev.w3.org/csswg/css-style-attr/<br />
;spec source (for editing)<br />
:http://dev.w3.org/csswg/css-style-attr/Overview.src.html<br />
;test suite<br />
:TBD<br />
;implementation reports of the test suite<br />
:TBD<br />
;issues list for the current draft<br />
:http://wiki.csswg.org/spec/css-style-attr<br />
<br />
===== CSS3 Color =====<br />
* CSS3 Color draft - achieved PR!<br />
;latest published draft<br />
:http://www.w3.org/TR/css3-color/<br />
;latest development / in progress draft<br />
:http://dev.w3.org/csswg/css3-color/<br />
;spec source (for editing)<br />
:http://dev.w3.org/csswg/css3-color/Overview.src.html<br />
;test suite<br />
:http://www.w3.org/Style/CSS/Test/CSS3/Color/20080721/<br />
;implementation reports of the test suite<br />
:http://www.w3.org/Style/CSS/Test/CSS3/Color/current/reports/<br />
;issues list for the current last call<br />
:http://wiki.csswg.org/spec/css3-color<br />
<br />
===== CSS3 UI =====<br />
Updated [http://dev.w3.org/csswg/css3-ui/ CSS3 UI Editor's draft] with:<br />
====== pointer-events ======<br />
* add '''pointer-events''' A way of specifying whether an element is opaque to pointer events (and receives them) or is transparent to them (letting them get handled by what's underneath.<br />
** CSSWG wiki: http://wiki.csswg.org/ideas/pointer-events<br />
** https://developer.mozilla.org/en/css/pointer-events - Mozilla spec<br />
*** shipped in Firefox 3.6 - demo: http://demos.hacks.mozilla.org/openweb/pointer-events/ ([https://bugzilla.mozilla.org/show_bug.cgi?id=380573 bug 380573]).<br />
*** See also SVG version: https://wiki.mozilla.org/SVG:Pointer-events<br />
** http://webkit.org/specs/PointerEventsProperty.html - Webkit spec<br />
*** shipped in Safari 4.0 ([https://bugs.webkit.org/show_bug.cgi?id=11395 bug 11395])<br />
** [http://people.opera.com/lstorset/TR/pointer-events/ Opera proposal]<br />
*** [http://lists.w3.org/Archives/Public/www-style/2010Aug/0407.html email proposing]<br />
*** [http://people.opera.com/lstorset/TR/pointer-events/ED-pointer-events-20100820.html CSS Hit Testing]<br />
** related: [[SVG:Pointer-events]]<br />
** key issue: precisely define default behavior (auto or visible etc.)<br />
** pointer events should be defined to affect:<br />
*** application of cursor property<br />
*** :hover<br />
*** mouseevents<br />
*** touchevents<br />
*** general concept of hit-testing so that elementFromPoint can be defined in terms of it (feedback fron annevk).<br />
====== text-overflow ======<br />
* '''text-overflow'''. incorporated '[https://developer.mozilla.org/En/CSS/text-overflow text-overflow]', since it's more a UI/overflow thing than a typesetting thing. There are at least 3 implementations (IE, WebKit, Opera), and has a bug against Firefox: [https://bugzilla.mozilla.org/show_bug.cgi?id=312156 312156]<br />
** Wanted for post-FF4; mats will be working on it, needs spec<br />
** W3C: http://dev.w3.org/csswg/css3-text/#text-overflow<br />
*** http://www.w3.org/blog/CSS/2009/11/25/resolutions_84 for bidi discussions<br />
** DevMo: https://developer.mozilla.org/En/CSS/text-overflow<br />
** Webkit: http://developer.apple.com/library/safari/documentation/appleapplications/reference/SafariCSSRef/Articles/StandardCSSProperties.html#//apple_ref/doc/uid/TP30001266-SW24<br />
** Microsoft/IE: http://msdn.microsoft.com/en-us/library/ms531174(VS.85).aspx<br />
** write test cases for 'ellipsis' and 'clip' (default value) and confirm cross-browser support.<br />
** Details that [https://bugzilla.mozilla.org/show_bug.cgi?id=312156#c21 RoC wants]:<br />
*** What style the ellipsis has (font, color, etc) ... does it come from the text or does it come from the element with text-overflow on it?<br />
**** from the element with text-overflow on it, this is what WebKit and Opera do<br />
**** need test case to see what Webkit, IE, Opera do<br />
*** does text-overflow inherit by default or not?<br />
**** Inherited: no<br />
*** how does it work with text-align:right, does the ellipsis go on the left?<br />
**** text-align does not affect text-overflow<br />
*** how does it work with bidi text, e.g. a line of Hebrew?<br />
**** it is rendered according to the 'direction' of the element.<br />
*** What about mixed bidi text e.g. English followed by Hebrew? I'm particuarly interested in the case of an LTR word followed by an RTL word that doesn't fit, e.g. <pre>english WERBEH</pre>where only "english HEB" fits, where should the ellipsis go?<br />
**** "english BEH…"<br />
*** Can bidi text make the ellipsis appear at the beginning of the line? <br />
**** bidi text? no. howevrer, setting 'direction:rtl' on the element will cause any ellipses to be drawn on the left side.<br />
*** what happens if there's replaced content near the end of the line, say an image?<br />
**** the image would wrap to the next line. but if there is white-space:nowrap, then...<br />
*** Do you get the ellipsis or does the image overflow? <br />
**** Images never cause ellipsis (in current implementations) per https://bugzilla.mozilla.org/show_bug.cgi?id=312156#c28<br />
*** If an ellipsis, where does the ellipsis go?<br />
**** it goes instead of the image and any text you have to remove in order to make the ellipsis fit.<br />
** add http://farm4.static.flickr.com/3635/3571013052_d419aff822_s.jpg CSS IS AWESOME examples/tests to the spec<br />
** capture issues and undefined aspects from fantasai/RoC emails as of 2011-031.<br />
** clarify text per emails from fantasai/RoC<br />
*** the effect of text-overflow:ellipsis on lines whose line boxes are not direct children of the block box(es) with text-overflow.<br />
*** the behavior of text-overflow:ellipsis on a block with 'overflow' of 'scroll' (no good interop, ideal behavior documented, needs screenshots)<br />
**** testcase from RoC: http://lists.w3.org/Archives/Public/www-style/2011Jan/att-0669/test.html<br />
**** Safari scrolls the ellipsis ... and doesn't reveal any additional text - this doesn't make sense to me (RoC, nor me Tantek) as a user. If I scroll I should get to see the rest of the content. (Agreed)<br />
**** Opera scrolls the text into view until the you can see the end of the text at which point the block scrolls no further (this is ideal beahvior -t). No ellipsis is display on the otherside of the block when you start scrolling characters off the start edge.<br />
***** This seems like the best behavior so far, with the exception that as a user (and developer) I'd expect to see the text that scrolled off the start of the block get replaced by an ellipsis rather than simply clipped (agreed precisely with RoC on this and have specified this expected behavior as a SHOULD)<br />
**** Testing IE9 in standards mode showed same behavior as Safari for scrolling+ellipsis.</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Tantek-Mozilla-Projects&diff=276219Tantek-Mozilla-Projects2011-01-06T23:31:46Z<p>Fantasai: </p>
<hr />
<div>Hi, I'm [[User:Tantek|Tantek Çelik]], and you've found my list of projects that I'm working on with Mozilla.<br />
<br />
I'm currently (as of 2010-146) a Mozilla contractor working with Chris Blizzard and the web [[standards]] team, focused on specification work, especially around web applications user interfaces and social/identity open web technologies. I participate in standards related [[events]] for both official organizations like W3C, and grass-roots efforts like microformats and ActivityStreams. If you have feedback for these groups, let me know!<br />
<br />
Specifications, efforts and summary status:<br />
* CSS<br />
** [[Tantek-Mozilla-projects#CSS_Style_Attributes|CSS Style Attributes]]: Achieved Candidate Recommendation (CR). Possible next steps, test cases/suite to help exit CR.<br />
** [[Tantek-Mozilla-projects#CSS3_Color|CSS3 Color]]: Achieved Proposed Recommendation (PR). Awaiting CSS 2.1 to reach PR.<br />
** [[Tantek-Mozilla-projects#CSS3_UI|CSS3 UI]]: editing CR toward producing a new LCWD.<br />
** [[Tantek-Mozilla-projects#UI_Layout|CSS UI Layout: Flex Box and Grid]]: Discussing differences and use cases with dbaron, and how to best design/define both for the benefit of web designers.<br />
** [[Tantek-Mozilla-projects#CSS3_Element|CSS3 Element]]: decide which draft to get it into (separate draft, Values and Units) and update draft accordingly.<br />
** [[Tantek-Mozilla-projects#CSS4_UI|CSS4 UI]]: collecting ideas, features, proposals towards writing a FPWD.<br />
** [[Tantek-Mozilla-projects#CSS4_Color|CSS4 Color]]: collecting ideas, features, proposals towards writing a FPWD.<br />
* [[Tantek-Mozilla-projects#HTML5_spec_improvements|HTML5]]: <br />
** follow-up on rejected/accepted spec improvement suggestions, figuring out next-steps for anything rejected<br />
** figure auto-close p issue. awaiting feedback from HTML5 Superfriends... then blog or email public-html about it.<br />
* [[vCard4]]: go through my critiques of draft 13 and check draft 15 accordingly, document which feedback was accepted or not (document email threads accordingly and decide on follow-up), review draft 15 thoroughly and write-up draft 15 review.<br />
* [[Tantek-Mozilla-projects#DOM_API_vendor_prefixing|DOM API vendor prefixing]]: discussing internally at Mozilla to build consensus, set a good example.<br />
<br />
Unfiled:<br />
* Review http://dev.w3.org/csswg/css-module/Overview.src.html<br />
<br />
See below for more details on each.<br />
<br />
== Web Apps ==<br />
=== UI Styling ===<br />
At a high level there are two general clusters of use cases that web pages/apps want/need to solve in terms of user interface fidelity.<br />
<br />
'''1. Beautiful Built-in Tweakable Controls.''' Pages that have some interactivity where the designer wants to use the built-in set of semantic user interface controls/inputs as long as they can just "tweak" them to match their web page/site design, e.g. color, background, typography. As long as the look and feel of built-in controls is beautiful enough both by default and with minor tweaks, then the hypothesis is that web designers will be happy/content to use built-in controls rather than go the extra mile to re-build custom controls with divs and javascript etc.<br />
<br />
Some data for this hypothesis: default iPhone/iPad controls are pretty enough that most developers are more than happy to use them - the default controls make their apps look beautiful, polished, without much work/tweaking (modulo layout/sizing etc.) If we can achieve that same experience with built-in controls, the theory is that most web designers will be happy to stick with built-in controls + CSS.<br />
<br />
'''2. Rich native-app-like experiences.''' Games. Media interfaces like WinAmp. There are always going to be some user interfaces where the developer wants nearly total control of the look and feel. Just take a look at typical Flash or Flex app UIs (note: some of those are egregiously inconsistent with the underlying OS platform just for the sake of being different - hard to avoid that but we can discourage it by making the cluster 1 solution easier and more accessible). In this case I'd like to see us figure out how to build hybrid controls that:<br />
<br />
a) Are built with the closest semantic built-in control for any particular custom control, <em>and</em><br />
<br />
b) Use a &lt;canvas&gt; for drawing custom appearance, with DOM event handlers drawing control-specific state in the canvas, <em>and</em><br />
<br />
c) Have text-based fall-back in the canvas.<br />
<br />
Example markup (event attributes/handlers omitted for simplicity)<br />
<br />
<pre>&lt;button&gt;&lt;canvas&gt; Play &lt;/canvas&gt;&lt;/button&gt;</pre><br />
<br />
(Now we just need a way to do that with text inputs too.)<br />
<br />
The goal in this second scenario is to enable building rich native-app-like user interfaces where the path of least resistance to building it uses building blocks that in themselves enable accessibility. I think this is both possible, and is a necessary course of action to avoid having to do "bolt-on" accessibility later.<br />
<br />
<br />
For now, the sections below focus on addressing/solving the first cluster of use cases first.<br />
<br />
The theory is that by addressing that first that it will become more obvious which specific real-world rich interfaces fall into the second cluster, and therefore we can design for that second cluster based on those specific interfaces.<br />
<br />
==== Styling HTML5 UI elements ====<br />
We need to define how Forms and other UI elements can be styled, and to synchronize our work with the W3C.<br />
<br />
Working with Mounir Lamouri on this: [[User:Mounir.lamouri/HTML5_Forms]]<br />
<br />
Each [[HTML5]] UI element must be complete to the following criteria:<br />
<br />
1. It must include pleasant and working UI, where appropriate.<br />
<br />
This is a big design challenge. Take a look at what Opera has done for example (in terms of challenges). Here is a simple test page which shows default renderings - compare in various browsers and try interacting with the new widgets especially in Opera:<br />
<br />
http://tantek.com/new-inputs.html<br />
<br />
See [[HTML5/input]] for more &lt;input&gt; element tests.<br />
<br />
* Need more sample/test/wiki pages for other HTML5 UI elements.<br />
<br />
2. You must be able to use CSS to style the element, especially the UI that we generate. This includes any pre-defined pseudo-selectors (invalid, required, icon, etc.)<br />
<br />
Agreed, this is an absolute requirement.<br />
<br />
Whenever there is ''any'' custom appearance of a form control, e.g. based on the new types, designers ''must'' be able to restyle them to fit in with their design. This means at a minimum:<br />
* ability to select specific "pieces" of any compound/composite form control for styling<br />
** feeds into requirements for CSS pseudo-elements<br />
** consider existing [http://www.w3.org/TR/css3-ui/#pseudo-elements CSS3-UI pseudo-elements]<br />
*** ::value can be used for selecting/styling placeholder text (see [https://bugzilla.mozilla.org/show_bug.cgi?id=457801#c25 bug 457801 comment 25])<br />
*** ::choices <br />
*** ::repeat-item <br />
*** ::repeat-index<br />
** consider additional pseudo-elements based on vendor prefixed pseudos<br />
*** Safari 5 supports pseudo-elements for restyling overflow scrollbars<br />
**** ::webkit-scrollbar-thumb<br />
**** ::webkit-scrollbar-track<br />
**** ::webkit-scrollbar<br />
* ability to select specific "states" of any form control (may require ability to select states of specific pieces as well - that will be a challenge though as pseudo-elements themselves cannot have pseudo-classes in CSS)<br />
** existing [http://www.w3.org/TR/css3-selectors/#UIstates Selectors UI pseudo-classes], and some notes on [http://www.w3.org/TR/html5/interactive-elements.html#pseudo-classes how HTML5 DOM property states trigger these pseudo-classes]<br />
*** :hover :active - based on mouse/pointer interactions. the challenge here is to find alternatives for touch based interfaces.<br />
*** :focus - an element which is currently accepting keyboard, pointer, or other input device events.<br />
*** :enabled and :disabled - based on the state of the "disabled" property on the element.<br />
*** :checked - based on the "checked" property on input types "radio" and "checkbox", and also on the "selected" property on option element.<br />
*** :indeterminate - based on the "indeterminate" property of the input types "radio" and "checkbox".<br />
*** :default - [http://www.w3.org/TR/html5/interactive-elements.html#selector-default default buttons or submit buttons]<br />
*** :valid and :invalid - input elements that are candidates for constraint validation and either do or don't (respectively) satisfy their constraints.<br />
*** :in-range and :out-of-range - input elements that are candidates for constraint validation and that are neither under nor overflowing (for :in-range) or either under/overflowing (for :out-of-range).<br />
*** :required and :optional - [http://www.w3.org/TR/html5/interactive-elements.html#selector-required see HTML5 description of being required / required attribute]<br />
*** :read-only and :read-write - [http://www.w3.org/TR/html5/interactive-elements.html#selector-read-only see HTML5 description of read-only vs read-write elements].<br />
** additional pseudo-selectors as needed for states/portions included in HTML5 forms elements features<br />
*** "placeholder" attribute - needs a new :-moz-placeholder pseudo-class ([https://bugzilla.mozilla.org/show_bug.cgi?id=457801 bug 457801])<br />
**** :placeholder pseudo-class needs to be proposed for CSS3.1 UI/Selectors.<br />
* typography<br />
** font properties<br />
** text properties<br />
** color<br />
* box properties<br />
** width<br />
** height<br />
** padding<br />
** border<br />
** margin<br />
** background<br />
** box-shadow<br />
<br />
<br />
3. If there's a constraint API the API must be complete.<br />
<br />
4. It should be [[Accessibility/HTML5_Forms|fully accessible]].<br />
<br />
==== Possible new HTML5 UI elements ====<br />
The new user interface elements in HTML5 cover quite a bit of Web Apps UI scenarios. There are both requests based on specific user/application scenarios, and there is also the full set of user interface objects represented by the values of the CSS3 UI 'appearance' property<br />
===== specific new elements =====<br />
* <code>&lt;menubar&gt;</code><br />
* pull-down-menu<br />
* context-menu<br />
* <code>&lt;input type="year"&gt;</code> - based on <code>&lt;time&gt;</code> element use case research<br />
* <code>&lt;input type="month-day"&gt;</code> - based on <code>&lt;time&gt;</code> element use case research<br />
<br />
===== CSS3 UI appearance values =====<br />
From [http://www.w3.org/TR/css3-ui/#appearance-val CSS3 UI 5.1. Appearance values]:<br />
<br />
Needs:<br />
* tab - a button that looks like the browser's tabbed windows tabs.<br />
* menubar - a menu of menus, typically arranged linearly, in a horizontal bar. <br />
* pull-down-menu - a menu where the name of the menu is displayed and the options remain hidden until the user activates the menu. When the user releases or deactivates the menu, the options are hidden again.<br />
* radio-group - a menu where the options are displayed as radio-buttons.<br />
* checkbox-group - a menu where the options are displayed as checkboxes. <br />
* outline-tree - a menu where the options can be shown or hidden with small widgets, often represented by a small triangle or plus and minus signs. might be possible to build one using <code>&lt;details&gt;</code> and <code>&lt;summary&gt;</code>.<br />
* combo-box - a field which is accompanied by a menu of preset values that can be used to quickly enter common or typical values. <br />
* signature - a field for entering a signature. <br />
<br />
Full list with equivalents:<br />
* icon - handled by 'icon' property and HTML5 Drag &amp; Drop<br />
* window - mostly handled outside of elements, except perhaps 'tooltip' which could be purely presentational<br />
* button - by default a push-button<br />
** push-button - <code>&lt;input type=button&gt;<code> and <code>&lt;button&gt;</code><br />
** hyperlink - <code>&lt;a href&gt;</code><br />
** radio-button - <code>&lt;input type="radio"&gt;</code><br />
** checkbox - <code>&lt;input type="checkbox"&gt;</code><br />
** menu-item - <code>&lt;option&gt;</code> and <code>&lt;optgroup&gt;</code><br />
** tab - no HTML5 equivalent<br />
* menu - by default a pop-up-menu<br />
** menubar - no HTML5 equivalent<br />
** pull-down-menu - no HTML5 equivalent<br />
** pop-up-menu - <code>&lt;select&gt;</code><br />
** list-menu - <code>&lt;select size=n</code> (where n>1)<br />
** radio-group - no HTML5 equivalent<br />
** checkbox-group - no HTML5 equivalent<br />
** outline-tree - no complete HTML5 equivalent but <code>&lt;details&gt;</code> and <code>&lt;summary&gt;</code> may help.<br />
** range - <code>&lt;input type="range"&gt;</code><br />
* field - <code>&lt;input type="text"&gt;</code> and <code>&lt;textarea&gt;</code><br />
** combo-box - no HTML5 equivalent<br />
** signature - no HTML5 equivalent<br />
** password - <code>&lt;input type="password"&gt;</code><br />
<br />
==== CSS Style Attributes ====<br />
;latest published draft (CR)<br />
:http://www.w3.org/TR/css-style-attr/<br />
;latest development / in progress draft<br />
:http://dev.w3.org/csswg/css-style-attr/<br />
;spec source (for editing)<br />
:http://dev.w3.org/csswg/css-style-attr/Overview.src.html<br />
;test suite<br />
:TBD<br />
;implementation reports of the test suite<br />
:TBD<br />
;issues list for the current draft<br />
:http://wiki.csswg.org/spec/css-style-attr<br />
<br />
===== remaining tasks =====<br />
* email Hixie to update reference to CSS Style Attributes draft in [http://www.whatwg.org/specs/web-apps/current-work/multipage/references.html#references HTML5 References]<br />
<br />
See also CSSWG wiki task list: http://wiki.csswg.org/spec/css-style-attr<br />
<br />
==== CSS3 UI ====<br />
;latest published draft<br />
:http://www.w3.org/TR/css3-ui/<br />
;latest development / in progress draft<br />
:http://dev.w3.org/csswg/css3-ui/<br />
;spec source (for editing)<br />
:http://dev.w3.org/csswg/css3-ui/Overview.src.html<br />
;test suite<br />
:TBD<br />
;implementation reports of the test suite<br />
:TBD<br />
;issues list for the current draft<br />
:http://wiki.csswg.org/spec/css3-ui<br />
<br />
===== remaining tasks =====<br />
Remaining tasks to get CSS3 UI to PR:<br />
<br />
* '''resolve issues'''. resolve/apply proposals from issues list: http://wiki.csswg.org/spec/css3-ui <br />
* '''overflow-x overflow-y'''. consider incorporating '''[https://developer.mozilla.org/En/CSS/Overflow-x overflow-x]''' and '''[https://developer.mozilla.org/En/CSS/Overflow-y overflow-y]'''<br />
** pull-in the entirety of section 16 from<br />
*** http://www.w3.org/Style/Group/css3-src/css3-box/#overflow<br />
** sync (incorporated) any updates/changes in 2.1:<br />
*** http://www.w3.org/Style/Group/css2-src/visufx.html#overflow<br />
** search www-style for issues related to 'overflow-x' and 'overflow-y'<br />
*** ask Anne van Kesteren and www-style directly<br />
** check that css3-marquee implicitly deals with overflow-x and overflow-y correctly<br />
*** http://www.w3.org/TR/css3-marquee/#the-overflow-style<br />
** investigate discussion of ink overflow vs layout overflow - [[User:Fantasai|fantasai]] will get more info on this. e.g. box-shadow should never trigger scrollbars. do margins? maybe they don't trigger overflow but if there is overflow anyways (something else triggers scrollbars), then margins influence the dimensions of the scrollable area.<br />
<br />
* <span id="text-overflow">'''text-overflow'''</span>. consider incorporating '[https://developer.mozilla.org/En/CSS/text-overflow text-overflow]', since it's more a UI/overflow thing than a typesetting thing. There are at least 3 implementations (IE, WebKit, Opera), and has a bug against Firefox: [https://bugzilla.mozilla.org/show_bug.cgi?id=312156 312156]<br />
** Wanted for post-FF4; mats will be working on it, needs spec<br />
** http://dev.w3.org/csswg/css3-text/#text-overflow<br />
** http://www.w3.org/blog/CSS/2009/11/25/resolutions_84 for bidi discussions<br />
** write test cases for 'ellipsis' and 'clip' (default value) and confirm cross-browser support.<br />
<br />
* '''implementation documentation'''. document claims of existing implementations (CSSWG implementers have until 2010-09-17 to submit claims of implementation)<br />
** Webkit CSS3 UI - http://lists.w3.org/Archives/Public/public-html/2009Sep/0060.html<br />
** Opera CSS3 UI - http://lists.w3.org/Archives/Public/public-html/2009Sep/0202.html<br />
** Mozilla CSS3 UI<br />
*** [https://developer.mozilla.org/en/CSS/:default :default]<br />
*** [https://developer.mozilla.org/En/CSS/:indeterminate :indeterminate]<br />
*** [https://developer.mozilla.org/En/CSS/::selection ::-moz-selection] - needs removal of prefix.<br />
*** [https://developer.mozilla.org/en/CSS/:-moz-placeholder :-moz-placeholder]<br />
*** more UI related pseudo-classes discussed in [https://developer.mozilla.org/en/CSS_Reference#Pseudo-classes devmo CSS Reference]<br />
*** [https://developer.mozilla.org/en/CSS/-moz-appearance -moz-appearance] - needs analysis to figure out if it complies with intent of 'appearance' property<br />
*** [https://developer.mozilla.org/En/CSS/Box-sizing -moz-box-sizing] - needs unprefixing ([https://bugzilla.mozilla.org/show_bug.cgi?id=243412 bug 243412]). <br />
**** extra value 'padding-box' is implemented - consider adding it to CSS3-UI<br />
*** 'cursor' - new values<br />
**** [https://developer.mozilla.org/en/CSS/-moz-alias alias] - verify works w/o prefix.<br />
**** [https://developer.mozilla.org/en/CSS/-moz-cell cell] - verify works w/o prefix.<br />
**** [https://developer.mozilla.org/en/CSS/-moz-copy copy] - verify works w/o prefix.<br />
*** [https://developer.mozilla.org/en/CSS/outline-offset outline-offset] - <br />
** Internet Explorer 8 CSS3 UI support - ??? (expect email from johnjan @ MS)<br />
** IE5/Mac CSS3 UI support - ???<br />
<br />
* draft and publish at least a minimal coverage test suite that covers those claims<br />
<br />
* document actual implementation results<br />
<br />
* reducing feature set down to what's been implemented in more than one browser<br />
** write new CSS3 UI LCWD editors draft with only non-at-risk features based on above implementation evidence (or imminent implementation - kept at risk)<br />
** write new UI Selectors FPWD editors draft with all new UI selectors (consider limiting to those with at least one implementation, any with less than 2 implementations, mark at risk up front)<br />
* collect/address new CSS3 UI LCWD issues as they are reported<br />
** respond to all the commenters on issues with proposed resolutions (hopefully thus addressing their concerns and resolving the issues accordingly)<br />
** incrementally draft new CSS3-UI CR draft accordingly<br />
<br />
* wait for new CSS3 UI LCWD last-call period to end<br />
<br />
* write UI Selectors LCWD - with features with at least one implementation, any with less than 2 implementations, mark at risk.<br />
<br />
* edit CSS3-UI CR draft accordingly that is ready for PR<br />
<br />
* WG processes for taking it to PR<br />
<br />
Remaining related Firefox bugs/development tasks (stub/incomplete)<br />
For each of these, figure out who is the right Mozilla developer to work on this and then work with to understand what it will take to get it implemented:<br />
* cursor / border-radius interaction bug: [https://bugzilla.mozilla.org/show_bug.cgi?id=595652 595652]<br />
** if/when fixed, add that detail to spec<br />
* cursor on root element applying to viewport: [https://bugzilla.mozilla.org/show_bug.cgi?id=568450 568450] <br />
** if/when fixed, add that detail to spec<br />
* icon support: http://www.w3.org/TR/css3-ui/#element<br />
** 'icon' property<br />
** 'content:icon' value<br />
* box-sizing prefix drop: https://bugzilla.mozilla.org/show_bug.cgi?id=243412<br />
* ...<br />
<br />
Additional CSS3 UI related features in Mozilla to investigate:<br />
* [https://developer.mozilla.org/en/CSS/-moz-user-focus -moz-user-focus]<br />
<br />
==== CSS4 UI ====<br />
* write CSS4 UI FPWD with:<br />
** previous CSS3-UI features that got dropped<br />
*** stuff from CSS3 UI that only had one implementation (that we believe is worthy of standardizing, or at least one other implementer expresses interest on)<br />
** other CSS features that are UI related in other CSS or other W3C specs<br />
*** :placeholder pseudo-class. related: [https://bugzilla.mozilla.org/show_bug.cgi?id=457801 bug 457801]<br />
*** '''overflow-radius''' per implementation: Mozilla supports [https://developer.mozilla.org/en/CSS/-moz-outline-radius -moz-outline-radius] (no second implementation however - thus in CSS4 UI)<br />
*** CSS3 Hyperlink<br />
*** [[HTML5]] inputs/forms features that are presentation related<br />
** new features<br />
*** CSS portions of [[Gecko:FullScreenAPI]], e.g. the new pseudo-classes<br />
*** new 'resize' values - e.g. 'grow-vertical', 'grow-horizontal'<br />
**** Facebook uses some JS to add rows to text areas when you hit the end of the available space. It feels nicer than a scrollbar because you can see all of what you typed -- the height of the text area just grows and grows as you need it. It would be great to have 'resize' property values that allow the browser to auto-grow a textarea as a user enters data, e.g. 'grow-horizontal', 'grow-vertical'. 'grow-vertical' would emulate the current behavior that FB does with JS.<br />
** forward reaching properties/values to enable native-like interfaces<br />
<br />
==== CSS3 Element ====<br />
===== write up moz-element proposal =====<br />
Firefox 4 implements background: -moz-element(#foo); to use element with id foo as the background per http://hacks.mozilla.org/2010/08/mozelement/ <br />
<br />
We're pursuing adding element(#foo) as an "at-risk" feature to the CSS3 Values and Units module.<br />
<br />
Proposal (worked with Tab Atkins)<br />
* http://lists.w3.org/Archives/Public/www-style/2010Aug/0635.html<br />
<br />
Threads:<br />
* [http://lists.w3.org/Archives/Public/www-style/2010Aug/thread.html#msg635 element() 2010-08]<br />
* [http://lists.w3.org/Archives/Public/www-style/2010Sep/thread.html#msg0 element() 2010-09]<br />
<br />
Thoughts:<br />
* CSS image() value - which Tab Atkins is already writing up<br />
* Add both to CSS3 Values and Units as at risk for taking it quickly to CR<br />
** in addition to the calc() work that David Baron is already doing in CSS3 Values and Units<br />
<br />
==== CSS4 Color ====<br />
* collect new features for CSS3.1/4 Color - color-correction<br />
** follow-up on color management properties for css3-color that were discussed at 2009 November TPAC CSS f2f (but later punted from css3-color to a future version).<br />
*** check minutes from that meeting for details on conclusions of the property (name, values etc.)<br />
*** contact Beth regarding level of implementation interest, plan to move forward with putting the color management property into a post-css3 working draft of the Color Module<br />
* write a first working draft of CSS3.1/4 Color with collected feature(s) (even if it includes just a new color management property)<br />
* find out where Hixie's tests went (was at http://test.csswg.org/source/contributors/hixie/incoming/css3-color/ ) and figure out what to do with them.<br />
<br />
=== DOM API vendor prefixing ===<br />
==== spec implementation problem statement ====<br />
Problem statement: the '''specification-implementation co-dependency problem'''.<br />
<br />
All standards in development have the challenging seemingly contradictory problems of:<br />
# '''needing some implementation to reality-check''' that the API/protocol/format "works" as intended, or is workable/usable<br />
# '''being stuck with a specific (often buggy) implementation''' once it ships because there's content/pages/apps out there that depend on it.<br />
<br />
There are three areas of the open web app platform that this has been problematic:<br />
# '''CSS'''. In the past, some properties were implemented, either as spec'd (and the spec was buggy), or in a way that made sense but incompatible with the spec (because the spec didn't make sense or was not useful to web authors), and then we got "stuck" with those implementations and were not able to update/fix the spec and the respective properties and/or values. Examples:<br />
## 'clip' property. mis-specified in CSS 2.0. implemented as presumed intended in IE4/Windows etc. but turned out to be buggy. some content started depending on it. we (CSS WG at the time) were unable to really fix it in a way that implementations could change, though [http://www.w3.org/TR/CSS21/visufx.html#clipping CSS 2.1 tries to fix clip].<br />
## 'word-wrap' property. in this case, created/proposed by Microsoft, and [http://msdn.microsoft.com/en-us/library/ms531186.aspx implemented as of IE5.5/Windows ca 2000], we are again, kind of stuck with the particular implementation. [http://www.codingforums.com/archive/index.php/t-2075.html Forum posts as of 2002 were recommending use of the literal word-wrap property]. Though since Microsoft did switch to advocating/supporting a prefixed version '-ms-word-wrap'. Note that it is also [https://developer.mozilla.org/en/CSS/word-wrap supported in Firefox 3.5 ca 2009], and it is in the latest (2007) version of the [http://www.w3.org/TR/2007/WD-css3-text-20070306/#word-wrap CSS3 Text spec which is just a working draft].<br />
### See related 'word-break' property ([http://www.w3.org/TR/2007/WD-css3-text-20070306/#word-break word-break in CSS3 Text WD] - latest, 2007), also [http://msdn.microsoft.com/en-us/library/ms531184.aspx initially (partially) implemented in Internet Explorer 5.x as word-break], and later switched to the prefixed '-ms-word-break'. [http://msdn.microsoft.com/en-us/library/cc351024%28VS.85%29.aspx More on CSS Compatibility and Internet Explorer].<br />
# '''HTML'''. Too many examples to list here. Some browsers are still stuck supporting <code>&lt;blink&gt;</code> and <code>&lt;marquee&gt;</code> (which has many odd details), nevermind the classic example of <code>&lt;table&gt;</code> layout, with tons of odd special cases and error-handling for compat, originally from Netscape's implementation, reverse-engineered by Microsoft in Internet Explorer, which has subsequently been reverse-engineered by every other browser.<br />
# '''DOM'''. In particular [http://www.w3.org/TR/2009/WD-webstorage-20091222/ Web Storage working draft] (e.g. the 'localStorage' attribute/property) was implemented in multiple browsers (IE8+, Chrome, Safari, Opera, Mozilla as of 2010 - date order unknown). By the time people discovered it was not threadsafe as specified, it was too late to change the spec to fix that problem - it would have broken too many apps/sites already written which apparently depended on it.<br />
<br />
==== existing solutions ====<br />
<br />
The only one of these areas of technology that has an explicit solution to the specification-implementation co-dependency problem is CSS, through vendor-prefixes.<br />
<br />
===== CSS vendor prefixes =====<br />
In the early 2000s the participants in the CSS working group agreed to formalize a way for implementors to build experimental implementations of new properties and values which were only in a working draft (not yet in a Candidate Recommendation) without saddling the property with implementation specific bugs that content would end up inadvertently depending on.<br />
<br />
CSS prefixing is fairly straight forward:<br />
<br />
<pre>- abbreviated_vendor_prefix - property_name</pre><br />
<br />
(spaces added for clarification of the different components)<br />
<br />
Examples include:<br />
* -moz-opacity<br />
* -o-border-radius<br />
* -webkit-border-radius<br />
* -ms-word-wrap<br />
<br />
===== CSS vendor prefixes case studies =====<br />
* '''border-radius'''. for a few years now browsers have been implementing ''vendor prefixed'' versions of the border-radius properties, web authors have been experimenting on the web, and the spec has iterated/improved based on feedback. Now we have a well-designed and road-tested 'border-radius' property in a CR spec and implementations are implementing that.<br />
* '''word-wrap vs whitespace: pre-wrap'''. interactions between new properties and new values on existing properties. See this [http://scottonwriting.net/sowBlog/archive/0000/00/00/163005.aspx example of the property vs value interaction] between the new 'word-wrap' property and the (sometimes prefixed) new 'pre-wrap' value on the 'whitespace' property. The point is to show how prefixing can actually work across different approaches to evolving CSS.<br />
<br />
===== CSS vendor prefixes successes =====<br />
Several well known web designers and developers have written at length about the successes of CSS vendor prefixes, and how they have both helped avoid problems from before, and actually improve the evolution of CSS.<br />
<br />
* [http://www.alistapart.com/articles/prefix-or-posthack/ A List Apart: Prefix or Posthack] by Eric Meyer<br />
* [http://www.webmonkey.com/2010/07/advice-from-the-css-guru-embrace-prefixes/ WIRED Webmonkey: Advice From the CSS Guru: Embrace Prefixes] by By Michael Calore<br />
* [http://www.the-haystack.com/2010/03/22/coping-with-css-prefixes/ The Haystack: Coping with CSS vendor prefixes] by Stephen Hay<br />
* [http://snook.ca/archives/html_and_css/not-supported Snook.ca: NOT SUPPORTED] by Jonathan Snook<br />
* [http://annevankesteren.nl/2010/03/css-vendor-prefix Anne van Kesteren: In defense of CSS prefixes] by Anne van Kesteren<br />
<br />
==== analysis of applicability ====<br />
Can we apply similar thinking and solutions to HTML and/or DOM?<br />
<br />
For HTML (or any markup) the thinking is no - because of the fact that an element only allows one tagname, there is no way to have content first use a vendor prefixed tagname (or tagnames from multiple vendors), and then also use a final unprefixed tagname all at the same time as part of a content evolution/transition strategy. CSS vendor prefixing works (as illustrated in the case studies) because authors ''can'' create style sheets that use multiple versions of a property (vendor prefixed and unprefixed) in one style sheet, together while evolving their content over time.<br />
<br />
For DOM, it is not only possible, but there are examples in the wild.<br />
<br />
[https://developer.mozilla.org/en/DOM/window.onmozorientation mozOrientation] is a good example of a vendor prefixed DOM interface implementation. (Note mozOrientation needs to be submitted to a W3C working group for standardization/iteration)<br />
<br />
==== simple DOM vendor prefixes proposal ====<br />
<br />
For all DOM interfaces that are:<br />
* Proprietary. No standards organization draft yet published. OR<br />
* In a W3C working draft, not yet in a Candidate Recommendation.<br />
<br />
Use vendor prefixed interfaces and values as follows:<br />
<br />
<pre>vendor_prefix _ unprefixed_name</pre><br />
<br />
E.g. in the above example of mozOrientation, we really should be using:<br />
<br />
<pre>moz_Orientation</pre><br />
<br />
This works because standard DOM APIs do not use underscores.<br />
<br />
Our goal is to establish a convention (like the above) for all such pre-CR DOM APIs that has the consensus of implementers so that we can avoid creating broken versions of APIs<br />
<br />
==== simple protocol scheme prefixes proposal ====<br />
The WebSockets specification (and iteration) provides a good example of a W3C Working Draft that has work also going on at the IETF (perhaps primarily), and there is a high likelihood of backwards incompatible changes being made to WebSockets's "ws:" protocol between different versions (-76, -00, -01).<br />
<br />
Thus it is worth considering prefixing implementations of the "ws:" protocol in order to break/rev as necessary instead of being locked into a specific draft due to premature reliant adoption.<br />
<br />
For all protocol schemes that are:<br />
* Proprietary. No standards organization draft yet published. OR<br />
* In a W3C or IETF working draft, not yet in a Candidate Recommendation, or perhaps public last call for IETF drafts (open to suggestions here).<br />
<br />
Use vendor prefixed protocol schemes as follows:<br />
<br />
<pre>vendor_prefix - unprefixed_name</pre><br />
<br />
E.g. WebSockets has a new ws: scheme, and we've implemented it in Firefox 4. We really should be using:<br />
<br />
<pre>moz-ws:</pre><br />
<br />
Our goal is to establish a convention (like the above) for all such pre-CR protocol schemes that has the consensus of implementers so that we can avoid creating broken versions of protocols.<br />
<br />
<br />
==== simple HTML attributes prefixes proposal ====<br />
Implementing prefixes on element names doesn't work because you can't have more than one element name per element, and thus prefixed versions would force developers to choose between unprefixed and a particular prefixed version.<br />
<br />
However elements do have multiple attributes, and thus prefixing can work for attributes.<br />
<br />
For all HTML attributes that are:<br />
* Proprietary. No standards organization draft yet published. OR<br />
* In a W3C working draft (e.g. New in HTML5), not yet in a Candidate Recommendation.<br />
<br />
Use vendor prefixed attributes as follows:<br />
<br />
<pre>vendor_prefix _ unprefixed_name</pre><br />
<br />
E.g. HTML5 has a new [http://www.w3.org/TR/html5/common-input-element-attributes.html#attr-input-pattern 'pattern' attribute], and we've implemented it in Firefox 4. We really should be using:<br />
<br />
<pre>moz_pattern</pre><br />
<br />
This works because standard HTML attributes do not use underscores.<br />
<br />
Our goal is to establish a convention (like the above) for all such pre-CR new HTML5 attributes that has the consensus of implementers so that we can avoid creating broken versions of elements.<br />
<br />
=== UI Layout ===<br />
CSS3 Flex Box and Grid<br />
<br />
There are two new CSS3 layout mechanisms being developed that could greatly assist with the layout of user interfaces.<br />
<br />
* CSS3 Flex Box<br />
** current working draft: http://www.w3.org/TR/css3-flexbox/<br />
** current editor's draft: http://dev.w3.org/csswg/css3-flexbox/ <br />
** Tab's proposed update: http://dev.w3.org/csswg/css3-flexbox/Overview.new.src.html<br />
** Tab's documentation of differences between editor's draft and his draft: http://www.xanthir.com/blog/b48Z0<br />
<br />
* CSS3 Grid<br />
** 2007-09-05 (current) working draft: http://www.w3.org/TR/css3-grid/<br />
** 2008-01-06 (current) editor's draft: http://dev.w3.org/csswg/css3-grid/<br />
<br />
* CSS3 Grid Align - not clear on the relation between Grid and Grid Align<br />
** Alex Mogilevsky's CSS3 Grid Align first draft: http://www.interoperabilitybridges.com/css3-grid-align/<br />
*** Alex's www-style email thread announcing his draft: http://lists.w3.org/Archives/Public/www-style/2010Oct/thread.html#msg787<br />
** 2010-11-18 (current) editor's draft: http://dev.w3.org/csswg/css3-grid-align/<br />
<br />
Some next-steps:<br />
* need to get in touch with Tab Atkins and catch-up on the current state of his Flex Box work vs. existing prefixed partial implementation in Firefox and Safari.<br />
** 2010-155 briefly spoke with Tab about flex box in irc and noted that I'm working on css3-color and css3-ui first.<br />
<br />
=== HTML5 spec improvements ===<br />
A set of tasks/projects for improving the state of the [[HTML5]] specification. Proposals will be moved to separate pages once mature enough for submission to [[standards]] bodies.<br />
<br />
Most of this has been moved to [[HTML5#spec_issues|HTML5: spec issues]].<br />
<br />
Next: follow-up on each, determining next steps on rejected proposals.<br />
<br />
==== waiting for HTML5 improvements ====<br />
==== keeping crappy stuff out ====<br />
===== simplify alt attribute guidance =====<br />
Moved to [[HTML5/img#alt_guidance_needs_simplification|HTML5/img]].<br />
===== remove meta Content-Language =====<br />
Moved to [[HTML5/meta#remove_meta_Content-Language|HTML5/meta]]<br />
==== upgrade HTML4 features to be more flexible and usable ====<br />
==== restoring pragmatic HTML4 things ====<br />
Moved to [[HTML5/cite#names_of_speakers|HTML5/cite]].<br />
==== improving new features ====<br />
===== iframe sandbox removal =====<br />
Moved to [[HTML5/iframe#drop_sandbox_attribute|HTML5/iframe]].<br />
===== summary naming =====<br />
Moved to [[HTML5/summary#summary_naming|HTML5/summary]]<br />
===== expand time =====<br />
Moved to [[HTML5/time#expand_time|HTML5/time]]<br />
===== nesting time =====<br />
Moved to [[HTML5/time#nesting_time|HTML5/time]]. am pm handling too.<br />
<br />
==== lower priority improvements ====<br />
* <code>&lt;meter&gt;</code> - poorly named. would prefer something like "gauge" but that's potentially hard(er) to spell. this is a bit bikesheddy though so not a high priority.<br />
<br />
<br />
== Web Apps Waiting For ==<br />
Tasks which are awaiting follow-ups from various standards bodies/lists. Reping as necessary to keep moving forward.<br />
<br />
=== CSS Waiting For ===<br />
==== CSS3 Backgrounds and Borders ====<br />
Waiting for CR of http://www.w3.org/TR/css3-background/<br />
<br />
And then: outstanding UI related issues:<br />
<br />
===== prefix removal from -moz-border-radius =====<br />
<br />
Currently Mozilla's border-radius properties are prefixed with -moz- and the following bugs/issues are preventing us from removing the prefix:<br />
<br />
* '''% values on border-radius.''' There is existing content (themes?) that depend on the legacy moz-border-radius implementation of % values that depend on the % of *width* in both dimensions.<br />
<br />
* '''clipping overflow and replaced elements.''' We don't currently clip overflow hidden and replaced elements (e.g. img, video, canvas) to rounded corners. We need to do to this for a proper/complete implementation that won't risk creating further legacy/backward compat problems.<br />
<br />
Bugzilla bugs:<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=431176 431176] - (border-radius) Tracking bug for remaining issues with CSS3 border-radius<br />
*[https://bugzilla.mozilla.org/show_bug.cgi?id=451134 451134] - change -moz-border-radius* properties to css3-background names<br />
<br />
== Social and Identity ==<br />
=== Related Features ===<br />
Features/people working with:<br />
* [[Account Manager]] - Dan Mills<br />
* Mozilla Contacts - Michael Hanson<br />
* Context Menu - Aza Raskin<br />
** see related: 2010-05-03 [http://mozillalabs.com/jetpack/2010/05/03/context-menu-module-microformats/ The Context Menu Module & Microformats] (JetPack)<br />
* ...<br />
<br />
=== Standards and Communities ===<br />
Standards and communities to engage with (recommended, grouped by related)<br />
<br />
identity / profiles / contacts<br />
* [[vCard4]] (IETF vcarddav)<br />
** write up problems with vCard4, divergence from vCard3/hCard/PoCo model, etc.<br />
* [[hCard]] (microformats.org)<br />
* Portable Contacts<br />
* microdata vcard vocab (W3C/WhatWG)<br />
* RelMeAuth<br />
* OpenID<br />
* WebFinger<br />
* ...<br />
<br />
social web<br />
* OAuth (including OAuth 2, xAuth, OWF)<br />
* Activity Streams<br />
* [http://federatedsocialweb.net/ Federated Social Web]<br />
* ...<br />
<br />
== Events ==<br />
[[Events]] I'm planning on participating in accordingly:<br />
* September 23-25 [http://north10.webdirections.org/ Web Directions USA in Atlanta]<br />
<br />
== Web Standards Coordination ==<br />
There are a lot of people at Mozilla working with a variety of different standards bodies. With Arun's recent departure, it's more clear than ever that we need to at least have some sort of a directory of standards organizations (and sub-orgs like working groups) listing who at Mozilla is working with each.<br />
<br />
* [[Standards]] - who is working on what standards in what organizations<br />
<br />
== Reference ==<br />
=== Pages ===<br />
See [[User:Tantek#pages|reference pages created]]<br />
<br />
=== Done ===<br />
Completed tasks, projects, events that have no further related active work items. Will likely move to its own page as it grows, in which case, I'll probably just keep *recently* finished items here and regularly archive them.<br />
<br />
==== Completed Events ====<br />
* June 1-3 Open Source Bridge, Portland, OR, http://opensourcebridge.org<br />
* June 28-30 Voices That Matter Web Design in SF http://www.voicesthatmatter.com/webdesign2010<br />
<br />
* July 6-10 [[Summit2010|Mozilla Summit]] in Whistler, Canada.<br />
* July 13 [http://www.realestateconnect.com/program/ Real Estate Connect San Francisco] (click on "Workshops »", search for "HTML5") at Hilton San Francisco Union Square, 333 O'Farrell Street, San Francisco, California<br />
** participating in WORKSHOP: ConnectTech / HTML5 Is Coming, Are You Ready?<br />
* July 17 [http://openwebcamp.org OpenWebCamp II] at Stanford<br />
* July 18 [http://federatedsocialweb.net/wiki/Main_Page Federated social web summit] ([http://federatedsocialweb.net/wiki/Schedule schedule])<br />
** more info: [http://status.net/2010/06/28/federated-social-web-summit-2010-announced announcement], [http://federatedsocialweb.net/wiki/FedAll2010/Invitations attendees]<br />
<br />
* August 23-25 [http://www.w3.org/Style/Group/2010/Oslo W3C CSS WG f2f in Oslo]<br />
<br />
* September 1-3 [http://2010.dConstruct.org/ dConstruct in Brighton] - web design and development<br />
<br />
==== Resolved HTML5 improvements and spec issues ====<br />
===== reject longdesc =====<br />
moved to: [[HTML5/img#reject_longdesc|HTML5/img]]<br />
===== allow date only on del ins datetime attribute =====<br />
* moved to [[HTML5/del#datetime_should_take_date|HTML5/del]].<br />
<br />
==== CSS ====<br />
===== CSS Style Attributes =====<br />
* CSS Style Attributes - achieved CR!<br />
;latest published draft (CR)<br />
:http://www.w3.org/TR/css-style-attr/<br />
;latest development / in progress draft<br />
:http://dev.w3.org/csswg/css-style-attr/<br />
;spec source (for editing)<br />
:http://dev.w3.org/csswg/css-style-attr/Overview.src.html<br />
;test suite<br />
:TBD<br />
;implementation reports of the test suite<br />
:TBD<br />
;issues list for the current draft<br />
:http://wiki.csswg.org/spec/css-style-attr<br />
<br />
===== CSS3 Color =====<br />
* CSS3 Color draft - achieved PR!<br />
;latest published draft<br />
:http://www.w3.org/TR/css3-color/<br />
;latest development / in progress draft<br />
:http://dev.w3.org/csswg/css3-color/<br />
;spec source (for editing)<br />
:http://dev.w3.org/csswg/css3-color/Overview.src.html<br />
;test suite<br />
:http://www.w3.org/Style/CSS/Test/CSS3/Color/20080721/<br />
;implementation reports of the test suite<br />
:http://www.w3.org/Style/CSS/Test/CSS3/Color/current/reports/<br />
;issues list for the current last call<br />
:http://wiki.csswg.org/spec/css3-color<br />
<br />
===== CSS3 UI =====<br />
Updated [http://dev.w3.org/csswg/css3-ui/ CSS3 UI Editor's draft] with:<br />
<br />
* add '''pointer-events''' A way of specifying whether an element is opaque to pointer events (and receives them) or is transparent to them (letting them get handled by what's underneath.<br />
** https://developer.mozilla.org/en/css/pointer-events - Mozilla spec<br />
*** shipped in Firefox 3.6 - demo: http://demos.hacks.mozilla.org/openweb/pointer-events/<br />
** http://webkit.org/specs/PointerEventsProperty.html - Webkit spec<br />
*** shipped in Safari 4.0<br />
** [http://lists.w3.org/Archives/Public/www-style/2010Aug/0407.html Opera proposal]<br />
*** [http://people.opera.com/lstorset/TR/pointer-events/ED-pointer-events-20100820.html CSS Hit Testing]<br />
** related: [[SVG:Pointer-events]]<br />
** key issue: precisely define default behavior (auto or visible etc.)<br />
** pointer events should be defined to affect:<br />
*** application of cursor property<br />
*** :hover<br />
*** mouseevents<br />
*** touchevents<br />
*** general concept of hit-testing so that elementFromPoint can be defined in terms of it (feedback fron annevk).</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Tantek-Mozilla-Projects&diff=273912Tantek-Mozilla-Projects2010-12-16T00:36:44Z<p>Fantasai: /* remaining tasks */ add text-overflow bidi notes</p>
<hr />
<div>Hi, I'm [[User:Tantek|Tantek Çelik]], and you've found my list of projects that I'm working on with Mozilla.<br />
<br />
I'm currently (as of 2010-146) a Mozilla contractor working with Chris Blizzard and the web [[standards]] team, focused on specification work, especially around web applications user interfaces and social/identity open web technologies. I participate in standards related [[events]] for both official organizations like W3C, and grass-roots efforts like microformats and ActivityStreams. If you have feedback for these groups, let me know!<br />
<br />
Specifications, efforts and summary status:<br />
* CSS<br />
** [[Tantek-Mozilla-projects#CSS_Style_Attributes|CSS Style Attributes]]: Achieved Candidate Recommendation (CR). Possible next steps, test cases/suite to help exit CR.<br />
** [[Tantek-Mozilla-projects#CSS3_Color|CSS3 Color]]: Achieved Proposed Recommendation (PR). Awaiting CSS 2.1 to reach PR.<br />
** [[Tantek-Mozilla-projects#CSS3_UI|CSS3 UI]]: editing CR toward producing a new LCWD.<br />
** [[Tantek-Mozilla-projects#UI_Layout|CSS UI Layout: Flex Box and Grid]]: Discussing differences and use cases with dbaron, and how to best design/define both for the benefit of web designers.<br />
** [[Tantek-Mozilla-projects#CSS3_Element|CSS3 Element]]: decide which draft to get it into (separate draft, Values and Units) and update draft accordingly.<br />
** [[Tantek-Mozilla-projects#CSS4_UI|CSS4 UI]]: collecting ideas, features, proposals towards writing a FPWD.<br />
** [[Tantek-Mozilla-projects#CSS4_Color|CSS4 Color]]: collecting ideas, features, proposals towards writing a FPWD.<br />
* [[Tantek-Mozilla-projects#HTML5_spec_improvements|HTML5]]: <br />
** follow-up on rejected/accepted spec improvement suggestions, figuring out next-steps for anything rejected<br />
** figure auto-close p issue. awaiting feedback from HTML5 Superfriends... then blog or email public-html about it.<br />
* [[vCard4]]: review draft 15 delta, check which of critiques of draft 13 were incorporated, email vcarddav accordingly, review draft 15 thoroughly, check for vcardddav email thread links for unresolved issues and document them here, with email follow-ups as needed.<br />
* [[Tantek-Mozilla-projects#DOM_API_vendor_prefixing|DOM API vendor prefixing]]: discussing internally at Mozilla to build consensus, set a good example.<br />
<br />
See below for more details on each.<br />
<br />
== Web Apps ==<br />
=== UI Styling ===<br />
At a high level there are two general clusters of use cases that web pages/apps want/need to solve in terms of user interface fidelity.<br />
<br />
'''1. Beautiful Built-in Tweakable Controls.''' Pages that have some interactivity where the designer wants to use the built-in set of semantic user interface controls/inputs as long as they can just "tweak" them to match their web page/site design, e.g. color, background, typography. As long as the look and feel of built-in controls is beautiful enough both by default and with minor tweaks, then the hypothesis is that web designers will be happy/content to use built-in controls rather than go the extra mile to re-build custom controls with divs and javascript etc.<br />
<br />
Some data for this hypothesis: default iPhone/iPad controls are pretty enough that most developers are more than happy to use them - the default controls make their apps look beautiful, polished, without much work/tweaking (modulo layout/sizing etc.) If we can achieve that same experience with built-in controls, the theory is that most web designers will be happy to stick with built-in controls + CSS.<br />
<br />
'''2. Rich native-app-like experiences.''' Games. Media interfaces like WinAmp. There are always going to be some user interfaces where the developer wants nearly total control of the look and feel. Just take a look at typical Flash or Flex app UIs (note: some of those are egregiously inconsistent with the underlying OS platform just for the sake of being different - hard to avoid that but we can discourage it by making the cluster 1 solution easier and more accessible). In this case I'd like to see us figure out how to build hybrid controls that:<br />
<br />
a) Are built with the closest semantic built-in control for any particular custom control, <em>and</em><br />
<br />
b) Use a &lt;canvas&gt; for drawing custom appearance, with DOM event handlers drawing control-specific state in the canvas, <em>and</em><br />
<br />
c) Have text-based fall-back in the canvas.<br />
<br />
Example markup (event attributes/handlers omitted for simplicity)<br />
<br />
<pre>&lt;button&gt;&lt;canvas&gt; Play &lt;/canvas&gt;&lt;/button&gt;</pre><br />
<br />
(Now we just need a way to do that with text inputs too.)<br />
<br />
The goal in this second scenario is to enable building rich native-app-like user interfaces where the path of least resistance to building it uses building blocks that in themselves enable accessibility. I think this is both possible, and is a necessary course of action to avoid having to do "bolt-on" accessibility later.<br />
<br />
<br />
For now, the sections below focus on addressing/solving the first cluster of use cases first.<br />
<br />
The theory is that by addressing that first that it will become more obvious which specific real-world rich interfaces fall into the second cluster, and therefore we can design for that second cluster based on those specific interfaces.<br />
<br />
==== Styling HTML5 UI elements ====<br />
We need to define how Forms and other UI elements can be styled, and to synchronize our work with the W3C.<br />
<br />
Working with Mounir Lamouri on this: [[User:Mounir.lamouri/HTML5_Forms]]<br />
<br />
Each [[HTML5]] UI element must be complete to the following criteria:<br />
<br />
1. It must include pleasant and working UI, where appropriate.<br />
<br />
This is a big design challenge. Take a look at what Opera has done for example (in terms of challenges). Here is a simple test page which shows default renderings - compare in various browsers and try interacting with the new widgets especially in Opera:<br />
<br />
http://tantek.com/new-inputs.html<br />
<br />
See [[HTML5/input]] for more &lt;input&gt; element tests.<br />
<br />
* Need more sample/test/wiki pages for other HTML5 UI elements.<br />
<br />
2. You must be able to use CSS to style the element, especially the UI that we generate. This includes any pre-defined pseudo-selectors (invalid, required, icon, etc.)<br />
<br />
Agreed, this is an absolute requirement.<br />
<br />
Whenever there is ''any'' custom appearance of a form control, e.g. based on the new types, designers ''must'' be able to restyle them to fit in with their design. This means at a minimum:<br />
* ability to select specific "pieces" of any compound/composite form control for styling<br />
** feeds into requirements for CSS pseudo-elements<br />
** consider existing [http://www.w3.org/TR/css3-ui/#pseudo-elements CSS3-UI pseudo-elements]<br />
*** ::value can be used for selecting/styling placeholder text (see [https://bugzilla.mozilla.org/show_bug.cgi?id=457801#c25 bug 457801 comment 25])<br />
*** ::choices <br />
*** ::repeat-item <br />
*** ::repeat-index<br />
** consider additional pseudo-elements based on vendor prefixed pseudos<br />
*** Safari 5 supports pseudo-elements for restyling overflow scrollbars<br />
**** ::webkit-scrollbar-thumb<br />
**** ::webkit-scrollbar-track<br />
**** ::webkit-scrollbar<br />
* ability to select specific "states" of any form control (may require ability to select states of specific pieces as well - that will be a challenge though as pseudo-elements themselves cannot have pseudo-classes in CSS)<br />
** existing [http://www.w3.org/TR/css3-selectors/#UIstates Selectors UI pseudo-classes], and some notes on [http://www.w3.org/TR/html5/interactive-elements.html#pseudo-classes how HTML5 DOM property states trigger these pseudo-classes]<br />
*** :hover :active - based on mouse/pointer interactions. the challenge here is to find alternatives for touch based interfaces.<br />
*** :focus - an element which is currently accepting keyboard, pointer, or other input device events.<br />
*** :enabled and :disabled - based on the state of the "disabled" property on the element.<br />
*** :checked - based on the "checked" property on input types "radio" and "checkbox", and also on the "selected" property on option element.<br />
*** :indeterminate - based on the "indeterminate" property of the input types "radio" and "checkbox".<br />
*** :default - [http://www.w3.org/TR/html5/interactive-elements.html#selector-default default buttons or submit buttons]<br />
*** :valid and :invalid - input elements that are candidates for constraint validation and either do or don't (respectively) satisfy their constraints.<br />
*** :in-range and :out-of-range - input elements that are candidates for constraint validation and that are neither under nor overflowing (for :in-range) or either under/overflowing (for :out-of-range).<br />
*** :required and :optional - [http://www.w3.org/TR/html5/interactive-elements.html#selector-required see HTML5 description of being required / required attribute]<br />
*** :read-only and :read-write - [http://www.w3.org/TR/html5/interactive-elements.html#selector-read-only see HTML5 description of read-only vs read-write elements].<br />
** additional pseudo-selectors as needed for states/portions included in HTML5 forms elements features<br />
*** "placeholder" attribute - needs a new :-moz-placeholder pseudo-class ([https://bugzilla.mozilla.org/show_bug.cgi?id=457801 bug 457801])<br />
**** :placeholder pseudo-class needs to be proposed for CSS3.1 UI/Selectors.<br />
* typography<br />
** font properties<br />
** text properties<br />
** color<br />
* box properties<br />
** width<br />
** height<br />
** padding<br />
** border<br />
** margin<br />
** background<br />
** box-shadow<br />
<br />
<br />
3. If there's a constraint API the API must be complete.<br />
<br />
4. It should be [[Accessibility/HTML5_Forms|fully accessible]].<br />
<br />
==== Possible new HTML5 UI elements ====<br />
The new user interface elements in HTML5 cover quite a bit of Web Apps UI scenarios. There are both requests based on specific user/application scenarios, and there is also the full set of user interface objects represented by the values of the CSS3 UI 'appearance' property<br />
===== specific new elements =====<br />
* <code>&lt;menubar&gt;</code><br />
* pull-down-menu<br />
* context-menu<br />
* <code>&lt;input type="year"&gt;</code> - based on <code>&lt;time&gt;</code> element use case research<br />
* <code>&lt;input type="month-day"&gt;</code> - based on <code>&lt;time&gt;</code> element use case research<br />
<br />
===== CSS3 UI appearance values =====<br />
From [http://www.w3.org/TR/css3-ui/#appearance-val CSS3 UI 5.1. Appearance values]:<br />
<br />
Needs:<br />
* tab - a button that looks like the browser's tabbed windows tabs.<br />
* menubar - a menu of menus, typically arranged linearly, in a horizontal bar. <br />
* pull-down-menu - a menu where the name of the menu is displayed and the options remain hidden until the user activates the menu. When the user releases or deactivates the menu, the options are hidden again.<br />
* radio-group - a menu where the options are displayed as radio-buttons.<br />
* checkbox-group - a menu where the options are displayed as checkboxes. <br />
* outline-tree - a menu where the options can be shown or hidden with small widgets, often represented by a small triangle or plus and minus signs. might be possible to build one using <code>&lt;details&gt;</code> and <code>&lt;summary&gt;</code>.<br />
* combo-box - a field which is accompanied by a menu of preset values that can be used to quickly enter common or typical values. <br />
* signature - a field for entering a signature. <br />
<br />
Full list with equivalents:<br />
* icon - handled by 'icon' property and HTML5 Drag &amp; Drop<br />
* window - mostly handled outside of elements, except perhaps 'tooltip' which could be purely presentational<br />
* button - by default a push-button<br />
** push-button - <code>&lt;input type=button&gt;<code> and <code>&lt;button&gt;</code><br />
** hyperlink - <code>&lt;a href&gt;</code><br />
** radio-button - <code>&lt;input type="radio"&gt;</code><br />
** checkbox - <code>&lt;input type="checkbox"&gt;</code><br />
** menu-item - <code>&lt;option&gt;</code> and <code>&lt;optgroup&gt;</code><br />
** tab - no HTML5 equivalent<br />
* menu - by default a pop-up-menu<br />
** menubar - no HTML5 equivalent<br />
** pull-down-menu - no HTML5 equivalent<br />
** pop-up-menu - <code>&lt;select&gt;</code><br />
** list-menu - <code>&lt;select size=n</code> (where n>1)<br />
** radio-group - no HTML5 equivalent<br />
** checkbox-group - no HTML5 equivalent<br />
** outline-tree - no complete HTML5 equivalent but <code>&lt;details&gt;</code> and <code>&lt;summary&gt;</code> may help.<br />
** range - <code>&lt;input type="range"&gt;</code><br />
* field - <code>&lt;input type="text"&gt;</code> and <code>&lt;textarea&gt;</code><br />
** combo-box - no HTML5 equivalent<br />
** signature - no HTML5 equivalent<br />
** password - <code>&lt;input type="password"&gt;</code><br />
<br />
==== CSS Style Attributes ====<br />
;latest published draft (CR)<br />
:http://www.w3.org/TR/css-style-attr/<br />
;latest development / in progress draft<br />
:http://dev.w3.org/csswg/css-style-attr/<br />
;spec source (for editing)<br />
:http://dev.w3.org/csswg/css-style-attr/Overview.src.html<br />
;test suite<br />
:TBD<br />
;implementation reports of the test suite<br />
:TBD<br />
;issues list for the current draft<br />
:http://wiki.csswg.org/spec/css-style-attr<br />
<br />
===== remaining tasks =====<br />
* email Hixie to update reference to CSS Style Attributes draft in [http://www.whatwg.org/specs/web-apps/current-work/multipage/references.html#references HTML5 References]<br />
<br />
See also CSSWG wiki task list: http://wiki.csswg.org/spec/css-style-attr<br />
<br />
==== CSS3 UI ====<br />
;latest published draft<br />
:http://www.w3.org/TR/css3-ui/<br />
;latest development / in progress draft<br />
:http://dev.w3.org/csswg/css3-ui/<br />
;spec source (for editing)<br />
:http://dev.w3.org/csswg/css3-ui/Overview.src.html<br />
;test suite<br />
:TBD<br />
;implementation reports of the test suite<br />
:TBD<br />
;issues list for the current draft<br />
:http://wiki.csswg.org/spec/css3-ui<br />
<br />
===== remaining tasks =====<br />
Remaining tasks to get CSS3 UI to PR:<br />
<br />
* '''resolve issues'''. resolve/apply proposals from issues list: http://wiki.csswg.org/spec/css3-ui <br />
* '''overflow-x overflow-y'''. consider incorporating '''[https://developer.mozilla.org/En/CSS/Overflow-x overflow-x]''' and '''[https://developer.mozilla.org/En/CSS/Overflow-y overflow-y]'''<br />
** pull-in the entirety of section 16 from<br />
*** http://www.w3.org/Style/Group/css3-src/css3-box/#overflow<br />
** sync (incorporated) any updates/changes in 2.1:<br />
*** http://www.w3.org/Style/Group/css2-src/visufx.html#overflow<br />
** search www-style for issues related to 'overflow-x' and 'overflow-y'<br />
*** ask Anne van Kesteren and www-style directly<br />
** check that css3-marquee implicitly deals with overflow-x and overflow-y correctly<br />
*** http://www.w3.org/TR/css3-marquee/#the-overflow-style<br />
** investigate discussion of ink overflow vs layout overflow - [[User:Fantasai|fantasai]] will get more info on this. e.g. box-shadow should never trigger scrollbars. do margins? maybe they don't trigger overflow but if there is overflow anyways (something else triggers scrollbars), then margins influence the dimensions of the scrollable area.<br />
<br />
* <span id="text-overflow">'''text-overflow'''</span>. consider incorporating '[https://developer.mozilla.org/En/CSS/text-overflow text-overflow]', since it's more a UI/overflow thing than a typesetting thing. There are at least 3 implementations (IE, WebKit, Opera), and has a bug against Firefox: [https://bugzilla.mozilla.org/show_bug.cgi?id=312156 312156]<br />
** Wanted for post-FF4; mats will be working on it, needs spec<br />
** http://dev.w3.org/csswg/css3-text/#text-overflow<br />
** http://www.w3.org/blog/CSS/2009/11/25/resolutions_84 for bidi discussions<br />
** write test cases for 'ellipsis' and 'clip' (default value) and confirm cross-browser support.<br />
<br />
* '''implementation documentation'''. document claims of existing implementations (CSSWG implementers have until 2010-09-17 to submit claims of implementation)<br />
** Webkit CSS3 UI - http://lists.w3.org/Archives/Public/public-html/2009Sep/0060.html<br />
** Opera CSS3 UI - http://lists.w3.org/Archives/Public/public-html/2009Sep/0202.html<br />
** Mozilla CSS3 UI<br />
*** [https://developer.mozilla.org/en/CSS/:default :default]<br />
*** [https://developer.mozilla.org/En/CSS/:indeterminate :indeterminate]<br />
*** [https://developer.mozilla.org/En/CSS/::selection ::-moz-selection] - needs removal of prefix.<br />
*** [https://developer.mozilla.org/en/CSS/:-moz-placeholder :-moz-placeholder]<br />
*** more UI related pseudo-classes discussed in [https://developer.mozilla.org/en/CSS_Reference#Pseudo-classes devmo CSS Reference]<br />
*** [https://developer.mozilla.org/en/CSS/-moz-appearance -moz-appearance] - needs analysis to figure out if it complies with intent of 'appearance' property<br />
*** [https://developer.mozilla.org/En/CSS/Box-sizing -moz-box-sizing] - needs unprefixing ([https://bugzilla.mozilla.org/show_bug.cgi?id=243412 bug 243412]). <br />
**** extra value 'padding-box' is implemented - consider adding it to CSS3-UI<br />
*** 'cursor' - new values<br />
**** [https://developer.mozilla.org/en/CSS/-moz-alias alias] - verify works w/o prefix.<br />
**** [https://developer.mozilla.org/en/CSS/-moz-cell cell] - verify works w/o prefix.<br />
**** [https://developer.mozilla.org/en/CSS/-moz-copy copy] - verify works w/o prefix.<br />
*** [https://developer.mozilla.org/en/CSS/outline-offset outline-offset] - <br />
** Internet Explorer 8 CSS3 UI support - ??? (expect email from johnjan @ MS)<br />
** IE5/Mac CSS3 UI support - ???<br />
<br />
* draft and publish at least a minimal coverage test suite that covers those claims<br />
<br />
* document actual implementation results<br />
<br />
* reducing feature set down to what's been implemented in more than one browser<br />
** write new CSS3 UI LCWD editors draft with only non-at-risk features based on above implementation evidence (or imminent implementation - kept at risk)<br />
** write new UI Selectors FPWD editors draft with all new UI selectors (consider limiting to those with at least one implementation, any with less than 2 implementations, mark at risk up front)<br />
* collect/address new CSS3 UI LCWD issues as they are reported<br />
** respond to all the commenters on issues with proposed resolutions (hopefully thus addressing their concerns and resolving the issues accordingly)<br />
** incrementally draft new CSS3-UI CR draft accordingly<br />
<br />
* wait for new CSS3 UI LCWD last-call period to end<br />
<br />
* write UI Selectors LCWD - with features with at least one implementation, any with less than 2 implementations, mark at risk.<br />
<br />
* edit CSS3-UI CR draft accordingly that is ready for PR<br />
<br />
* WG processes for taking it to PR<br />
<br />
Remaining related Firefox bugs/development tasks (stub/incomplete)<br />
For each of these, figure out who is the right Mozilla developer to work on this and then work with to understand what it will take to get it implemented:<br />
* cursor / border-radius interaction bug: [https://bugzilla.mozilla.org/show_bug.cgi?id=595652 595652]<br />
** if/when fixed, add that detail to spec<br />
* cursor on root element applying to viewport: [https://bugzilla.mozilla.org/show_bug.cgi?id=568450 568450] <br />
** if/when fixed, add that detail to spec<br />
* icon support: http://www.w3.org/TR/css3-ui/#element<br />
** 'icon' property<br />
** 'content:icon' value<br />
* box-sizing prefix drop: https://bugzilla.mozilla.org/show_bug.cgi?id=243412<br />
* ...<br />
<br />
Additional CSS3 UI related features in Mozilla to investigate:<br />
* [https://developer.mozilla.org/en/CSS/-moz-user-focus -moz-user-focus]<br />
<br />
==== CSS4 UI ====<br />
* write CSS4 UI FPWD with:<br />
** previous CSS3-UI features that got dropped<br />
*** stuff from CSS3 UI that only had one implementation (that we believe is worthy of standardizing, or at least one other implementer expresses interest on)<br />
** other CSS features that are UI related in other CSS or other W3C specs<br />
*** :placeholder pseudo-class. related: [https://bugzilla.mozilla.org/show_bug.cgi?id=457801 bug 457801]<br />
*** '''overflow-radius''' per implementation: Mozilla supports [https://developer.mozilla.org/en/CSS/-moz-outline-radius -moz-outline-radius] (no second implementation however - thus in CSS4 UI)<br />
*** CSS3 Hyperlink<br />
*** [[HTML5]] inputs/forms features that are presentation related<br />
** new features<br />
*** CSS portions of [[Gecko:FullScreenAPI]], e.g. the new pseudo-classes<br />
*** new 'resize' values - e.g. 'grow-vertical', 'grow-horizontal'<br />
**** Facebook uses some JS to add rows to text areas when you hit the end of the available space. It feels nicer than a scrollbar because you can see all of what you typed -- the height of the text area just grows and grows as you need it. It would be great to have 'resize' property values that allow the browser to auto-grow a textarea as a user enters data, e.g. 'grow-horizontal', 'grow-vertical'. 'grow-vertical' would emulate the current behavior that FB does with JS.<br />
** forward reaching properties/values to enable native-like interfaces<br />
<br />
==== CSS3 Element ====<br />
===== write up moz-element proposal =====<br />
Firefox 4 implements background: -moz-element(#foo); to use element with id foo as the background per http://hacks.mozilla.org/2010/08/mozelement/ <br />
<br />
We're pursuing adding element(#foo) as an "at-risk" feature to the CSS3 Values and Units module.<br />
<br />
Proposal (worked with Tab Atkins)<br />
* http://lists.w3.org/Archives/Public/www-style/2010Aug/0635.html<br />
<br />
Threads:<br />
* [http://lists.w3.org/Archives/Public/www-style/2010Aug/thread.html#msg635 element() 2010-08]<br />
* [http://lists.w3.org/Archives/Public/www-style/2010Sep/thread.html#msg0 element() 2010-09]<br />
<br />
Thoughts:<br />
* CSS image() value - which Tab Atkins is already writing up<br />
* Add both to CSS3 Values and Units as at risk for taking it quickly to CR<br />
** in addition to the calc() work that David Baron is already doing in CSS3 Values and Units<br />
<br />
==== CSS4 Color ====<br />
* collect new features for CSS3.1/4 Color - color-correction<br />
** follow-up on color management properties for css3-color that were discussed at 2009 November TPAC CSS f2f (but later punted from css3-color to a future version).<br />
*** check minutes from that meeting for details on conclusions of the property (name, values etc.)<br />
*** contact Beth regarding level of implementation interest, plan to move forward with putting the color management property into a post-css3 working draft of the Color Module<br />
* write a first working draft of CSS3.1/4 Color with collected feature(s) (even if it includes just a new color management property)<br />
* find out where Hixie's tests went (was at http://test.csswg.org/source/contributors/hixie/incoming/css3-color/ ) and figure out what to do with them.<br />
<br />
=== DOM API vendor prefixing ===<br />
==== spec implementation problem statement ====<br />
Problem statement: the '''specification-implementation co-dependency problem'''.<br />
<br />
All standards in development have the challenging seemingly contradictory problems of:<br />
# '''needing some implementation to reality-check''' that the API/protocol/format "works" as intended, or is workable/usable<br />
# '''being stuck with a specific (often buggy) implementation''' once it ships because there's content/pages/apps out there that depend on it.<br />
<br />
There are three areas of the open web app platform that this has been problematic:<br />
# '''CSS'''. In the past, some properties were implemented, either as spec'd (and the spec was buggy), or in a way that made sense but incompatible with the spec (because the spec didn't make sense or was not useful to web authors), and then we got "stuck" with those implementations and were not able to update/fix the spec and the respective properties and/or values. Examples:<br />
## 'clip' property. mis-specified in CSS 2.0. implemented as presumed intended in IE4/Windows etc. but turned out to be buggy. some content started depending on it. we (CSS WG at the time) were unable to really fix it in a way that implementations could change, though [http://www.w3.org/TR/CSS21/visufx.html#clipping CSS 2.1 tries to fix clip].<br />
## 'word-wrap' property. in this case, created/proposed by Microsoft, and [http://msdn.microsoft.com/en-us/library/ms531186.aspx implemented as of IE5.5/Windows ca 2000], we are again, kind of stuck with the particular implementation. [http://www.codingforums.com/archive/index.php/t-2075.html Forum posts as of 2002 were recommending use of the literal word-wrap property]. Though since Microsoft did switch to advocating/supporting a prefixed version '-ms-word-wrap'. Note that it is also [https://developer.mozilla.org/en/CSS/word-wrap supported in Firefox 3.5 ca 2009], and it is in the latest (2007) version of the [http://www.w3.org/TR/2007/WD-css3-text-20070306/#word-wrap CSS3 Text spec which is just a working draft].<br />
### See related 'word-break' property ([http://www.w3.org/TR/2007/WD-css3-text-20070306/#word-break word-break in CSS3 Text WD] - latest, 2007), also [http://msdn.microsoft.com/en-us/library/ms531184.aspx initially (partially) implemented in Internet Explorer 5.x as word-break], and later switched to the prefixed '-ms-word-break'. [http://msdn.microsoft.com/en-us/library/cc351024%28VS.85%29.aspx More on CSS Compatibility and Internet Explorer].<br />
# '''HTML'''. Too many examples to list here. Some browsers are still stuck supporting <code>&lt;blink&gt;</code> and <code>&lt;marquee&gt;</code> (which has many odd details), nevermind the classic example of <code>&lt;table&gt;</code> layout, with tons of odd special cases and error-handling for compat, originally from Netscape's implementation, reverse-engineered by Microsoft in Internet Explorer, which has subsequently been reverse-engineered by every other browser.<br />
# '''DOM'''. In particular [http://www.w3.org/TR/2009/WD-webstorage-20091222/ Web Storage working draft] (e.g. the 'localStorage' attribute/property) was implemented in multiple browsers (IE8+, Chrome, Safari, Opera, Mozilla as of 2010 - date order unknown). By the time people discovered it was not threadsafe as specified, it was too late to change the spec to fix that problem - it would have broken too many apps/sites already written which apparently depended on it.<br />
<br />
==== existing solutions ====<br />
<br />
The only one of these areas of technology that has an explicit solution to the specification-implementation co-dependency problem is CSS, through vendor-prefixes.<br />
<br />
===== CSS vendor prefixes =====<br />
In the early 2000s the participants in the CSS working group agreed to formalize a way for implementors to build experimental implementations of new properties and values which were only in a working draft (not yet in a Candidate Recommendation) without saddling the property with implementation specific bugs that content would end up inadvertently depending on.<br />
<br />
CSS prefixing is fairly straight forward:<br />
<br />
<pre>- abbreviated_vendor_prefix - property_name</pre><br />
<br />
(spaces added for clarification of the different components)<br />
<br />
Examples include:<br />
* -moz-opacity<br />
* -o-border-radius<br />
* -webkit-border-radius<br />
* -ms-word-wrap<br />
<br />
===== CSS vendor prefixes case studies =====<br />
* '''border-radius'''. for a few years now browsers have been implementing ''vendor prefixed'' versions of the border-radius properties, web authors have been experimenting on the web, and the spec has iterated/improved based on feedback. Now we have a well-designed and road-tested 'border-radius' property in a CR spec and implementations are implementing that.<br />
* '''word-wrap vs whitespace: pre-wrap'''. interactions between new properties and new values on existing properties. See this [http://scottonwriting.net/sowBlog/archive/0000/00/00/163005.aspx example of the property vs value interaction] between the new 'word-wrap' property and the (sometimes prefixed) new 'pre-wrap' value on the 'whitespace' property. The point is to show how prefixing can actually work across different approaches to evolving CSS.<br />
<br />
===== CSS vendor prefixes successes =====<br />
Several well known web designers and developers have written at length about the successes of CSS vendor prefixes, and how they have both helped avoid problems from before, and actually improve the evolution of CSS.<br />
<br />
* [http://www.alistapart.com/articles/prefix-or-posthack/ A List Apart: Prefix or Posthack] by Eric Meyer<br />
* [http://www.webmonkey.com/2010/07/advice-from-the-css-guru-embrace-prefixes/ WIRED Webmonkey: Advice From the CSS Guru: Embrace Prefixes] by By Michael Calore<br />
* [http://www.the-haystack.com/2010/03/22/coping-with-css-prefixes/ The Haystack: Coping with CSS vendor prefixes] by Stephen Hay<br />
* [http://snook.ca/archives/html_and_css/not-supported Snook.ca: NOT SUPPORTED] by Jonathan Snook<br />
* [http://annevankesteren.nl/2010/03/css-vendor-prefix Anne van Kesteren: In defense of CSS prefixes] by Anne van Kesteren<br />
<br />
==== analysis of applicability ====<br />
Can we apply similar thinking and solutions to HTML and/or DOM?<br />
<br />
For HTML (or any markup) the thinking is no - because of the fact that an element only allows one tagname, there is no way to have content first use a vendor prefixed tagname (or tagnames from multiple vendors), and then also use a final unprefixed tagname all at the same time as part of a content evolution/transition strategy. CSS vendor prefixing works (as illustrated in the case studies) because authors ''can'' create style sheets that use multiple versions of a property (vendor prefixed and unprefixed) in one style sheet, together while evolving their content over time.<br />
<br />
For DOM, it is not only possible, but there are examples in the wild.<br />
<br />
[https://developer.mozilla.org/en/DOM/window.onmozorientation mozOrientation] is a good example of a vendor prefixed DOM interface implementation. (Note mozOrientation needs to be submitted to a W3C working group for standardization/iteration)<br />
<br />
==== simple DOM vendor prefixes proposal ====<br />
<br />
For all DOM interfaces that are:<br />
* Proprietary. No standards organization draft yet published. OR<br />
* In a W3C working draft, not yet in a Candidate Recommendation.<br />
<br />
Use vendor prefixed interfaces and values as follows:<br />
<br />
<pre>vendor_prefix _ unprefixed_name</pre><br />
<br />
E.g. in the above example of mozOrientation, we really should be using:<br />
<br />
<pre>moz_Orientation</pre><br />
<br />
This works because standard DOM APIs do not use underscores.<br />
<br />
Our goal is to establish a convention (like the above) for all such pre-CR DOM APIs that has the consensus of implementers so that we can avoid creating broken versions of APIs<br />
<br />
==== simple protocol scheme prefixes proposal ====<br />
The WebSockets specification (and iteration) provides a good example of a W3C Working Draft that has work also going on at the IETF (perhaps primarily), and there is a high likelihood of backwards incompatible changes being made to WebSockets's "ws:" protocol between different versions (-76, -00, -01).<br />
<br />
Thus it is worth considering prefixing implementations of the "ws:" protocol in order to break/rev as necessary instead of being locked into a specific draft due to premature reliant adoption.<br />
<br />
For all protocol schemes that are:<br />
* Proprietary. No standards organization draft yet published. OR<br />
* In a W3C or IETF working draft, not yet in a Candidate Recommendation, or perhaps public last call for IETF drafts (open to suggestions here).<br />
<br />
Use vendor prefixed protocol schemes as follows:<br />
<br />
<pre>vendor_prefix - unprefixed_name</pre><br />
<br />
E.g. WebSockets has a new ws: scheme, and we've implemented it in Firefox 4. We really should be using:<br />
<br />
<pre>moz-ws:</pre><br />
<br />
Our goal is to establish a convention (like the above) for all such pre-CR protocol schemes that has the consensus of implementers so that we can avoid creating broken versions of protocols.<br />
<br />
<br />
==== simple HTML attributes prefixes proposal ====<br />
Implementing prefixes on element names doesn't work because you can't have more than one element name per element, and thus prefixed versions would force developers to choose between unprefixed and a particular prefixed version.<br />
<br />
However elements do have multiple attributes, and thus prefixing can work for attributes.<br />
<br />
For all HTML attributes that are:<br />
* Proprietary. No standards organization draft yet published. OR<br />
* In a W3C working draft (e.g. New in HTML5), not yet in a Candidate Recommendation.<br />
<br />
Use vendor prefixed attributes as follows:<br />
<br />
<pre>vendor_prefix _ unprefixed_name</pre><br />
<br />
E.g. HTML5 has a new [http://www.w3.org/TR/html5/common-input-element-attributes.html#attr-input-pattern 'pattern' attribute], and we've implemented it in Firefox 4. We really should be using:<br />
<br />
<pre>moz_pattern</pre><br />
<br />
This works because standard HTML attributes do not use underscores.<br />
<br />
Our goal is to establish a convention (like the above) for all such pre-CR new HTML5 attributes that has the consensus of implementers so that we can avoid creating broken versions of elements.<br />
<br />
=== UI Layout ===<br />
CSS3 Flex Box and Grid<br />
<br />
There are two new CSS3 layout mechanisms being developed that could greatly assist with the layout of user interfaces.<br />
<br />
* CSS3 Flex Box<br />
** current working draft: http://www.w3.org/TR/css3-flexbox/<br />
** current editor's draft: http://dev.w3.org/csswg/css3-flexbox/ <br />
** Tab's proposed update: http://dev.w3.org/csswg/css3-flexbox/Overview.new.src.html<br />
** Tab's documentation of differences between editor's draft and his draft: http://www.xanthir.com/blog/b48Z0<br />
<br />
* CSS3 Grid<br />
** 2007-09-05 (current) working draft: http://www.w3.org/TR/css3-grid/<br />
** 2008-01-06 (current) editor's draft: http://dev.w3.org/csswg/css3-grid/<br />
<br />
* CSS3 Grid Align - not clear on the relation between Grid and Grid Align<br />
** Alex Mogilevsky's CSS3 Grid Align first draft: http://www.interoperabilitybridges.com/css3-grid-align/<br />
*** Alex's www-style email thread announcing his draft: http://lists.w3.org/Archives/Public/www-style/2010Oct/thread.html#msg787<br />
** 2010-11-18 (current) editor's draft: http://dev.w3.org/csswg/css3-grid-align/<br />
<br />
Some next-steps:<br />
* need to get in touch with Tab Atkins and catch-up on the current state of his Flex Box work vs. existing prefixed partial implementation in Firefox and Safari.<br />
** 2010-155 briefly spoke with Tab about flex box in irc and noted that I'm working on css3-color and css3-ui first.<br />
<br />
=== HTML5 spec improvements ===<br />
A set of tasks/projects for improving the state of the [[HTML5]] specification. Proposals will be moved to separate pages once mature enough for submission to [[standards]] bodies.<br />
<br />
Most of this has been moved to [[HTML5#spec_issues|HTML5: spec issues]].<br />
<br />
Next: follow-up on each, determining next steps on rejected proposals.<br />
<br />
==== waiting for HTML5 improvements ====<br />
==== keeping crappy stuff out ====<br />
===== simplify alt attribute guidance =====<br />
Moved to [[HTML5/img#alt_guidance_needs_simplification|HTML5/img]].<br />
===== remove meta Content-Language =====<br />
Moved to [[HTML5/meta#remove_meta_Content-Language|HTML5/meta]]<br />
==== upgrade HTML4 features to be more flexible and usable ====<br />
==== restoring pragmatic HTML4 things ====<br />
Moved to [[HTML5/cite#names_of_speakers|HTML5/cite]].<br />
==== improving new features ====<br />
===== iframe sandbox removal =====<br />
Moved to [[HTML5/iframe#drop_sandbox_attribute|HTML5/iframe]].<br />
===== summary naming =====<br />
Moved to [[HTML5/summary#summary_naming|HTML5/summary]]<br />
===== expand time =====<br />
Moved to [[HTML5/time#expand_time|HTML5/time]]<br />
===== nesting time =====<br />
Moved to [[HTML5/time#nesting_time|HTML5/time]]. am pm handling too.<br />
<br />
==== lower priority improvements ====<br />
* <code>&lt;meter&gt;</code> - poorly named. would prefer something like "gauge" but that's potentially hard(er) to spell. this is a bit bikesheddy though so not a high priority.<br />
<br />
<br />
== Web Apps Waiting For ==<br />
Tasks which are awaiting follow-ups from various standards bodies/lists. Reping as necessary to keep moving forward.<br />
<br />
=== CSS Waiting For ===<br />
==== CSS3 Backgrounds and Borders ====<br />
Waiting for CR of http://www.w3.org/TR/css3-background/<br />
<br />
And then: outstanding UI related issues:<br />
<br />
===== prefix removal from -moz-border-radius =====<br />
<br />
Currently Mozilla's border-radius properties are prefixed with -moz- and the following bugs/issues are preventing us from removing the prefix:<br />
<br />
* '''% values on border-radius.''' There is existing content (themes?) that depend on the legacy moz-border-radius implementation of % values that depend on the % of *width* in both dimensions.<br />
<br />
* '''clipping overflow and replaced elements.''' We don't currently clip overflow hidden and replaced elements (e.g. img, video, canvas) to rounded corners. We need to do to this for a proper/complete implementation that won't risk creating further legacy/backward compat problems.<br />
<br />
Bugzilla bugs:<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=431176 431176] - (border-radius) Tracking bug for remaining issues with CSS3 border-radius<br />
*[https://bugzilla.mozilla.org/show_bug.cgi?id=451134 451134] - change -moz-border-radius* properties to css3-background names<br />
<br />
== Social and Identity ==<br />
=== Related Features ===<br />
Features/people working with:<br />
* [[Account Manager]] - Dan Mills<br />
* Mozilla Contacts - Michael Hanson<br />
* Context Menu - Aza Raskin<br />
** see related: 2010-05-03 [http://mozillalabs.com/jetpack/2010/05/03/context-menu-module-microformats/ The Context Menu Module & Microformats] (JetPack)<br />
* ...<br />
<br />
=== Standards and Communities ===<br />
Standards and communities to engage with (recommended, grouped by related)<br />
<br />
identity / profiles / contacts<br />
* [[vCard4]] (IETF vcarddav)<br />
** write up problems with vCard4, divergence from vCard3/hCard/PoCo model, etc.<br />
* [[hCard]] (microformats.org)<br />
* Portable Contacts<br />
* microdata vcard vocab (W3C/WhatWG)<br />
* RelMeAuth<br />
* OpenID<br />
* WebFinger<br />
* ...<br />
<br />
social web<br />
* OAuth (including OAuth 2, xAuth, OWF)<br />
* Activity Streams<br />
* [http://federatedsocialweb.net/ Federated Social Web]<br />
* ...<br />
<br />
== Events ==<br />
[[Events]] I'm planning on participating in accordingly:<br />
* September 23-25 [http://north10.webdirections.org/ Web Directions USA in Atlanta]<br />
<br />
== Web Standards Coordination ==<br />
There are a lot of people at Mozilla working with a variety of different standards bodies. With Arun's recent departure, it's more clear than ever that we need to at least have some sort of a directory of standards organizations (and sub-orgs like working groups) listing who at Mozilla is working with each.<br />
<br />
* [[Standards]] - who is working on what standards in what organizations<br />
<br />
== Reference ==<br />
=== Pages ===<br />
See [[User:Tantek#pages|reference pages created]]<br />
<br />
=== Done ===<br />
Completed tasks, projects, events that have no further related active work items. Will likely move to its own page as it grows, in which case, I'll probably just keep *recently* finished items here and regularly archive them.<br />
<br />
==== Completed Events ====<br />
* June 1-3 Open Source Bridge, Portland, OR, http://opensourcebridge.org<br />
* June 28-30 Voices That Matter Web Design in SF http://www.voicesthatmatter.com/webdesign2010<br />
<br />
* July 6-10 [[Summit2010|Mozilla Summit]] in Whistler, Canada.<br />
* July 13 [http://www.realestateconnect.com/program/ Real Estate Connect San Francisco] (click on "Workshops »", search for "HTML5") at Hilton San Francisco Union Square, 333 O'Farrell Street, San Francisco, California<br />
** participating in WORKSHOP: ConnectTech / HTML5 Is Coming, Are You Ready?<br />
* July 17 [http://openwebcamp.org OpenWebCamp II] at Stanford<br />
* July 18 [http://federatedsocialweb.net/wiki/Main_Page Federated social web summit] ([http://federatedsocialweb.net/wiki/Schedule schedule])<br />
** more info: [http://status.net/2010/06/28/federated-social-web-summit-2010-announced announcement], [http://federatedsocialweb.net/wiki/FedAll2010/Invitations attendees]<br />
<br />
* August 23-25 [http://www.w3.org/Style/Group/2010/Oslo W3C CSS WG f2f in Oslo]<br />
<br />
* September 1-3 [http://2010.dConstruct.org/ dConstruct in Brighton] - web design and development<br />
<br />
==== Resolved HTML5 improvements and spec issues ====<br />
===== reject longdesc =====<br />
moved to: [[HTML5/img#reject_longdesc|HTML5/img]]<br />
===== allow date only on del ins datetime attribute =====<br />
* moved to [[HTML5/del#datetime_should_take_date|HTML5/del]].<br />
<br />
==== CSS ====<br />
===== CSS Style Attributes =====<br />
* CSS Style Attributes - achieved CR!<br />
;latest published draft (CR)<br />
:http://www.w3.org/TR/css-style-attr/<br />
;latest development / in progress draft<br />
:http://dev.w3.org/csswg/css-style-attr/<br />
;spec source (for editing)<br />
:http://dev.w3.org/csswg/css-style-attr/Overview.src.html<br />
;test suite<br />
:TBD<br />
;implementation reports of the test suite<br />
:TBD<br />
;issues list for the current draft<br />
:http://wiki.csswg.org/spec/css-style-attr<br />
<br />
===== CSS3 Color =====<br />
* CSS3 Color draft - achieved PR!<br />
;latest published draft<br />
:http://www.w3.org/TR/css3-color/<br />
;latest development / in progress draft<br />
:http://dev.w3.org/csswg/css3-color/<br />
;spec source (for editing)<br />
:http://dev.w3.org/csswg/css3-color/Overview.src.html<br />
;test suite<br />
:http://www.w3.org/Style/CSS/Test/CSS3/Color/20080721/<br />
;implementation reports of the test suite<br />
:http://www.w3.org/Style/CSS/Test/CSS3/Color/current/reports/<br />
;issues list for the current last call<br />
:http://wiki.csswg.org/spec/css3-color<br />
<br />
===== CSS3 UI =====<br />
Updated [http://dev.w3.org/csswg/css3-ui/ CSS3 UI Editor's draft] with:<br />
<br />
* add '''pointer-events''' A way of specifying whether an element is opaque to pointer events (and receives them) or is transparent to them (letting them get handled by what's underneath.<br />
** https://developer.mozilla.org/en/css/pointer-events - Mozilla spec<br />
*** shipped in Firefox 3.6 - demo: http://demos.hacks.mozilla.org/openweb/pointer-events/<br />
** http://webkit.org/specs/PointerEventsProperty.html - Webkit spec<br />
*** shipped in Safari 4.0<br />
** [http://lists.w3.org/Archives/Public/www-style/2010Aug/0407.html Opera proposal]<br />
*** [http://people.opera.com/lstorset/TR/pointer-events/ED-pointer-events-20100820.html CSS Hit Testing]<br />
** related: [[SVG:Pointer-events]]<br />
** key issue: precisely define default behavior (auto or visible etc.)<br />
** pointer events should be defined to affect:<br />
*** application of cursor property<br />
*** :hover<br />
*** mouseevents<br />
*** touchevents<br />
*** general concept of hit-testing so that elementFromPoint can be defined in terms of it (feedback fron annevk).</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Modules&diff=267700Modules2010-11-15T19:01:49Z<p>Fantasai: link to module ownership essay</p>
<hr />
<div>This page is an index of pages listing the Module Owners and their Peers for all Mozilla Modules, broken down into different areas of the project.<br />
<br />
Mozilla operates under a [[http://www.mozilla.org/hacking/module-ownership.html|module ownership governance system]]. A Module is a discrete unit of code or activity. An Owner is the person in charge of a Module. A Peer is a person whom the Owner has appointed to help them. A Module may have multiple Owners and multiple Peers.<br />
<br />
Questions about module ownership should be directed to the owner or peers of the [[Modules/Activities#Module_Ownership_System|Module Ownership module]].<br />
<br />
* [[Modules/All|All in one big list]]<br />
<br />
* [[Modules/Firefox|Firefox]]<br />
* [[Modules/Thunderbird|Thunderbird]]<br />
* [[Modules/SeaMonkey|SeaMonkey]]<br />
* [[Modules/Calendar|Calendar]]<br />
<br />
* [[Modules/Toolkit|Toolkit]]<br />
* [[Modules/Core|Core]]<br />
* [[Modules/MailNews_Core|MailNews Core]]<br />
<br />
* [[Modules/Bugzilla|Bugzilla]]<br />
* [[Modules/Other|Other]] (code modules which aren't in any of the above categories)<br />
* [[Modules/Activities|Activities]] (non-code)</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Tantek-Mozilla-Projects&diff=252725Tantek-Mozilla-Projects2010-09-12T23:31:02Z<p>Fantasai: /* remaining tasks */</p>
<hr />
<div>Hi, I'm [[User:Tantek|Tantek Çelik]], and you've found my list of projects that I'm working on with Mozilla.<br />
<br />
I'm currently (as of 2010-146) a Mozilla contractor working with Chris Blizzard and the web standards team, focused on specification work, especially around web applications user interfaces and social/identity open web technologies.<br />
<br />
In particular:<br />
<br />
== Web Apps ==<br />
=== UI Styling ===<br />
At a high level there are two general clusters of use cases that web pages/apps want/need to solve in terms of user interface fidelity.<br />
<br />
'''1. Beautiful Built-in Tweakable Controls.''' Pages that have some interactivity where the designer wants to use the built-in set of semantic user interface controls/inputs as long as they can just "tweak" them to match their web page/site design, e.g. color, background, typography. As long as the look and feel of built-in controls is beautiful enough both by default and with minor tweaks, then the hypothesis is that web designers will be happy/content to use built-in controls rather than go the extra mile to re-build custom controls with divs and javascript etc.<br />
<br />
Some data for this hypothesis: default iPhone/iPad controls are pretty enough that most developers are more than happy to use them - the default controls make their apps look beautiful, polished, without much work/tweaking (modulo layout/sizing etc.) If we can achieve that same experience with built-in controls, the theory is that most web designers will be happy to stick with built-in controls + CSS.<br />
<br />
'''2. Rich native-app-like experiences.''' Games. Media interfaces like WinAmp. There are always going to be some user interfaces where the developer wants nearly total control of the look and feel. Just take a look at typical Flash or Flex app UIs (note: some of those are egregiously inconsistent with the underlying OS platform just for the sake of being different - hard to avoid that but we can discourage it by making the cluster 1 solution easier and more accessible). In this case I'd like to see us figure out how to build hybrid controls that:<br />
<br />
a) Are built with the closest semantic built-in control for any particular custom control, <em>and</em><br />
<br />
b) Use a &lt;canvas&gt; for drawing custom appearance, with DOM event handlers drawing control-specific state in the canvas, <em>and</em><br />
<br />
c) Have text-based fall-back in the canvas.<br />
<br />
Example markup (event attributes/handlers omitted for simplicity)<br />
<br />
<pre>&lt;button&gt;&lt;canvas&gt; Play &lt;/canvas&gt;&lt;/button&gt;</pre><br />
<br />
(Now we just need a way to do that with text inputs too.)<br />
<br />
The goal in this second scenario is to enable building rich native-app-like user interfaces where the path of least resistance to building it uses building blocks that in themselves enable accessibility. I think this is both possible, and is a necessary course of action to avoid having to do "bolt-on" accessibility later.<br />
<br />
<br />
For now, the sections below focus on addressing/solving the first cluster of use cases first.<br />
<br />
The theory is that by addressing that first that it will become more obvious which specific real-world rich interfaces fall into the second cluster, and therefore we can design for that second cluster based on those specific interfaces.<br />
<br />
==== Styling HTML5 UI elements ====<br />
We need to define how Forms and other UI elements can be styled, and to synchronize our work with the W3C.<br />
<br />
Working with Mounir Lamouri on this: [[User:Mounir.lamouri/HTML5_Forms]]<br />
<br />
Each [[HTML5]] UI element must be complete to the following criteria:<br />
<br />
1. It must include pleasant and working UI, where appropriate.<br />
<br />
This is a big design challenge. Take a look at what Opera has done for example (in terms of challenges). Here is a simple test page which shows default renderings - compare in various browsers and try interacting with the new widgets especially in Opera:<br />
<br />
http://tantek.com/new-inputs.html<br />
<br />
See [[HTML5/input]] for more &lt;input&gt; element tests.<br />
<br />
* Need more sample/test/wiki pages for other HTML5 UI elements.<br />
<br />
2. You must be able to use CSS to style the element, especially the UI that we generate. This includes any pre-defined pseudo-selectors (invalid, required, icon, etc.)<br />
<br />
Agreed, this is an absolute requirement.<br />
<br />
Whenever there is ''any'' custom appearance of a form control, e.g. based on the new types, designers ''must'' be able to restyle them to fit in with their design. This means at a minimum:<br />
* ability to select specific "pieces" of any compound/composite form control for styling<br />
** feeds into requirements for CSS pseudo-elements<br />
** consider existing [http://www.w3.org/TR/css3-ui/#pseudo-elements CSS3-UI pseudo-elements]<br />
*** ::value can be used for selecting/styling placeholder text (see [https://bugzilla.mozilla.org/show_bug.cgi?id=457801#c25 bug 457801 comment 25])<br />
*** ::choices <br />
*** ::repeat-item <br />
*** ::repeat-index<br />
** consider additional pseudo-elements based on vendor prefixed pseudos<br />
*** Safari 5 supports pseudo-elements for restyling overflow scrollbars<br />
**** ::webkit-scrollbar-thumb<br />
**** ::webkit-scrollbar-track<br />
**** ::webkit-scrollbar<br />
* ability to select specific "states" of any form control (may require ability to select states of specific pieces as well - that will be a challenge though as pseudo-elements themselves cannot have pseudo-classes in CSS)<br />
** existing [http://www.w3.org/TR/css3-selectors/#UIstates Selectors UI pseudo-classes], and some notes on [http://www.w3.org/TR/html5/interactive-elements.html#pseudo-classes how HTML5 DOM property states trigger these pseudo-classes]<br />
*** :hover :active - based on mouse/pointer interactions. the challenge here is to find alternatives for touch based interfaces.<br />
*** :focus - an element which is currently accepting keyboard, pointer, or other input device events.<br />
*** :enabled and :disabled - based on the state of the "disabled" property on the element.<br />
*** :checked - based on the "checked" property on input types "radio" and "checkbox", and also on the "selected" property on option element.<br />
*** :indeterminate - based on the "indeterminate" property of the input types "radio" and "checkbox".<br />
*** :default - [http://www.w3.org/TR/html5/interactive-elements.html#selector-default default buttons or submit buttons]<br />
*** :valid and :invalid - input elements that are candidates for constraint validation and either do or don't (respectively) satisfy their constraints.<br />
*** :in-range and :out-of-range - input elements that are candidates for constraint validation and that are neither under nor overflowing (for :in-range) or either under/overflowing (for :out-of-range).<br />
*** :required and :optional - [http://www.w3.org/TR/html5/interactive-elements.html#selector-required see HTML5 description of being required / required attribute]<br />
*** :read-only and :read-write - [http://www.w3.org/TR/html5/interactive-elements.html#selector-read-only see HTML5 description of read-only vs read-write elements].<br />
** additional pseudo-selectors as needed for states/portions included in HTML5 forms elements features<br />
*** "placeholder" attribute - needs a new :-moz-placeholder pseudo-class ([https://bugzilla.mozilla.org/show_bug.cgi?id=457801 bug 457801])<br />
**** :placeholder pseudo-class needs to be proposed for CSS3.1 UI/Selectors.<br />
* typography<br />
** font properties<br />
** text properties<br />
** color<br />
* box properties<br />
** width<br />
** height<br />
** padding<br />
** border<br />
** margin<br />
** background<br />
** box-shadow<br />
<br />
<br />
3. If there's a constraint API the API must be complete.<br />
<br />
4. It should be [[Accessibility/HTML5_Forms|fully accessible]].<br />
<br />
==== Possible new HTML5 UI elements ====<br />
The new user interface elements in HTML5 cover quite a bit of Web Apps UI scenarios. There are both requests based on specific user/application scenarios, and there is also the full set of user interface objects represented by the values of the CSS3 UI 'appearance' property<br />
===== specific new elements =====<br />
* <code>&lt;menubar&gt;</code><br />
* pull-down-menu<br />
* context-menu<br />
* <code>&lt;input type="year"&gt;</code> - based on <code>&lt;time&gt;</code> element use case research<br />
* <code>&lt;input type="month-day"&gt;</code> - based on <code>&lt;time&gt;</code> element use case research<br />
<br />
===== CSS3 UI appearance values =====<br />
From [http://www.w3.org/TR/css3-ui/#appearance-val CSS3 UI 5.1. Appearance values]:<br />
<br />
Needs:<br />
* tab - a button that looks like the browser's tabbed windows tabs.<br />
* menubar - a menu of menus, typically arranged linearly, in a horizontal bar. <br />
* pull-down-menu - a menu where the name of the menu is displayed and the options remain hidden until the user activates the menu. When the user releases or deactivates the menu, the options are hidden again.<br />
* radio-group - a menu where the options are displayed as radio-buttons.<br />
* checkbox-group - a menu where the options are displayed as checkboxes. <br />
* outline-tree - a menu where the options can be shown or hidden with small widgets, often represented by a small triangle or plus and minus signs. might be possible to build one using <code>&lt;details&gt;</code> and <code>&lt;summary&gt;</code>.<br />
* combo-box - a field which is accompanied by a menu of preset values that can be used to quickly enter common or typical values. <br />
* signature - a field for entering a signature. <br />
<br />
Full list with equivalents:<br />
* icon - handled by 'icon' property and HTML5 Drag &amp; Drop<br />
* window - mostly handled outside of elements, except perhaps 'tooltip' which could be purely presentational<br />
* button - by default a push-button<br />
** push-button - <code>&lt;input type=button&gt;<code> and <code>&lt;button&gt;</code><br />
** hyperlink - <code>&lt;a href&gt;</code><br />
** radio-button - <code>&lt;input type="radio"&gt;</code><br />
** checkbox - <code>&lt;input type="checkbox"&gt;</code><br />
** menu-item - <code>&lt;option&gt;</code> and <code>&lt;optgroup&gt;</code><br />
** tab - no HTML5 equivalent<br />
* menu - by default a pop-up-menu<br />
** menubar - no HTML5 equivalent<br />
** pull-down-menu - no HTML5 equivalent<br />
** pop-up-menu - <code>&lt;select&gt;</code><br />
** list-menu - <code>&lt;select size=n</code> (where n>1)<br />
** radio-group - no HTML5 equivalent<br />
** checkbox-group - no HTML5 equivalent<br />
** outline-tree - no complete HTML5 equivalent but <code>&lt;details&gt;</code> and <code>&lt;summary&gt;</code> may help.<br />
** range - <code>&lt;input type="range"&gt;</code><br />
* field - <code>&lt;input type="text"&gt;</code> and <code>&lt;textarea&gt;</code><br />
** combo-box - no HTML5 equivalent<br />
** signature - no HTML5 equivalent<br />
** password - <code>&lt;input type="password"&gt;</code><br />
<br />
==== CSS3 Color ====<br />
;latest published draft<br />
:http://www.w3.org/TR/css3-color/<br />
;latest development / in progress draft<br />
:http://dev.w3.org/csswg/css3-color/<br />
;spec source (for editing)<br />
:http://dev.w3.org/csswg/css3-color/Overview.src.html<br />
;test suite<br />
:http://www.w3.org/Style/CSS/Test/CSS3/Color/20080721/<br />
;implementation reports of the test suite<br />
:http://www.w3.org/Style/CSS/Test/CSS3/Color/current/reports/<br />
;issues list for the current last call<br />
:http://wiki.csswg.org/spec/css3-color - once these issues are addressed, it should be ready to go to PR.<br />
<br />
===== remaining tasks =====<br />
Remaining tasks to get CSS3 Color to PR:<br />
* resolve any remaining open issues in the issues list<br />
* respond to all the commenters in the issues list with proposed resolutions (hopefully thus addressing their concerns and resolving the issues accordingly)<br />
** update the disposition of comments accordingly with responses<br />
* do the remaining editing on the draft<br />
** one of them has an action on Chris Lilley to write text<br />
** ...<br />
* reconfirm that any/all dependent specs are in CR (or later)<br />
* collect new features for CSS3.1/4 Color<br />
** follow-up on color management properties for css3-color that were discussed at 2009 November TPAC CSS f2f (but later punted from css3-color to a future version).<br />
*** check minutes from that meeting for details on conclusions of the property (name, values etc.)<br />
*** contact Beth regarding level of implementation interest, plan to move forward with putting the color management property into a post-css3 working draft of the Color Module<br />
* write a first working draft of CSS3.1/4 Color with collected feature(s) (even if it includes just a new color management property)<br />
* find out where Hixie's tests went (was at http://test.csswg.org/source/contributors/hixie/incoming/css3-color/ ) and figure out what to do with them.<br />
<br />
==== CSS3 UI ====<br />
;latest published draft<br />
:http://www.w3.org/TR/css3-ui/<br />
;latest development / in progress draft<br />
:http://dev.w3.org/csswg/css3-ui/<br />
;spec source (for editing)<br />
:http://dev.w3.org/csswg/css3-ui/Overview.src.html<br />
;test suite<br />
:TBD<br />
;implementation reports of the test suite<br />
:TBD<br />
;issues list for the current draft<br />
:http://wiki.csswg.org/spec/css3-ui<br />
<br />
===== remaining tasks =====<br />
Remaining tasks to get CSS3 UI to PR:<br />
<br />
* 'cursor' detail: on the root element, setting cursor applies to the border-edge (per 2.1 or later CSS spec that defines it e.g. CSS3 Borders and Backgrounds). See also 'pointer-events' which can modify it. [note from fantasai: wouldn't it make more sense for cursor on the root to propagate to the entire canvas? there's no other way to change the cursor on the canvas]<br />
<br />
* add '''pointer-events''' A way of specifying whether an element is opaque to pointer events (and receives them) or is transparent to them (letting them get handled by what's underneath.<br />
** https://developer.mozilla.org/en/css/pointer-events - Mozilla spec<br />
*** shipped in Firefox 3.6 - demo: http://demos.hacks.mozilla.org/openweb/pointer-events/<br />
** http://webkit.org/specs/PointerEventsProperty.html - Webkit spec<br />
*** shipped in Safari 4.0<br />
** [http://lists.w3.org/Archives/Public/www-style/2010Aug/0407.html Opera proposal]<br />
*** [http://people.opera.com/lstorset/TR/pointer-events/ED-pointer-events-20100820.html CSS Hit Testing]<br />
** related: [[SVG:Pointer-events]]<br />
** key issue: precisely define default behavior (auto or visible etc.)<br />
** pointer events should be defined to affect:<br />
*** application of cursor property<br />
*** :hover<br />
*** mouseevents<br />
*** touchevents<br />
*** general concept of hit-testing so that elementFromPoint can be defined in terms of it (feedback fron annevk).<br />
<br />
* consider incorporating '''[https://developer.mozilla.org/En/CSS/Overflow-x overflow-x]''' and '''[https://developer.mozilla.org/En/CSS/Overflow-y overflow-y]'''<br />
** pull-in the entirety of section 16 from<br />
*** http://www.w3.org/Style/Group/css3-src/css3-box/#overflow<br />
** sync (incorporated) any updates/changes in 2.1:<br />
*** http://www.w3.org/Style/Group/css2-src/visufx.html#overflow<br />
** search www-style for issues related to 'overflow-x' and 'overflow-y'<br />
*** ask Anne van Kesteren and www-style directly<br />
** check that css3-marquee implicitly deals with overflow-x and overflow-y correctly<br />
*** http://www.w3.org/TR/css3-marquee/#the-overflow-style<br />
** investigate discussion of ink overflow vs layout overflow - [[User:Fantasai|fantasai]] will get more info on this. e.g. box-shadow should never trigger scrollbars. do margins? maybe they don't trigger overflow but if there is overflow anyways (something else triggers scrollbars), then margins influence the dimensions of the scrollable area.<br />
<br />
* consider stealing and speccing ''text-overflow'', since it's more a UI/overflow thing than a typesetting thing. There are at least 3 implementations (IE, WebKit, Opera) See https://bugzilla.mozilla.org/show_bug.cgi?id=312156<br />
<br />
* consider adding '''overflow-radius''' per implementation(s)<br />
** Mozilla supports [https://developer.mozilla.org/en/CSS/-moz-outline-radius -moz-outline-radius]<br />
<br />
* document claims of existing implementations (CSSWG implementers have until 2010-09-17 to submit claims of implementation)<br />
** Webkit CSS3 UI - http://lists.w3.org/Archives/Public/public-html/2009Sep/0060.html<br />
** Opera CSS3 UI - http://lists.w3.org/Archives/Public/public-html/2009Sep/0202.html<br />
** Mozilla CSS3 UI<br />
*** [https://developer.mozilla.org/en/CSS/:default :default]<br />
*** [https://developer.mozilla.org/En/CSS/:indeterminate :indeterminate]<br />
*** [https://developer.mozilla.org/En/CSS/::selection ::-moz-selection] - needs removal of prefix.<br />
*** [https://developer.mozilla.org/en/CSS/:-moz-placeholder :-moz-placeholder]<br />
*** more UI related pseudo-classes discussed in [https://developer.mozilla.org/en/CSS_Reference#Pseudo-classes devmo CSS Reference]<br />
*** [https://developer.mozilla.org/en/CSS/-moz-appearance -moz-appearance] - needs analysis to figure out if it complies with intent of 'appearance' property<br />
*** [https://developer.mozilla.org/En/CSS/Box-sizing -moz-box-sizing] - needs unprefixing ([https://bugzilla.mozilla.org/show_bug.cgi?id=243412 bug 243412]). <br />
**** extra value 'padding-box' is implemented - consider adding it to CSS3-UI<br />
*** 'cursor' - new values<br />
**** [https://developer.mozilla.org/en/CSS/-moz-alias alias] - verify works w/o prefix.<br />
**** [https://developer.mozilla.org/en/CSS/-moz-cell cell] - verify works w/o prefix.<br />
**** [https://developer.mozilla.org/en/CSS/-moz-copy copy] - verify works w/o prefix.<br />
*** [https://developer.mozilla.org/en/CSS/outline-offset outline-offset] - <br />
** Internet Explorer 8 CSS3 UI support - ??? (expect email from johnjan @ MS)<br />
** IE5/Mac CSS3 UI support - ???<br />
<br />
* draft and publish at least a minimal coverage test suite that covers those claims<br />
<br />
* document actual implementation results<br />
<br />
* reducing feature set down to what's been implemented in more than one browser<br />
** write new CSS3 UI LCWD editors draft with only non-at-risk features based on above implementation evidence (or imminent implementation - kept at risk)<br />
** write new UI Selectors FPWD editors draft with all new UI selectors (consider limiting to those with at least one implementation, any with less than 2 implementations, mark at risk up front)<br />
** write CSS4 UI FPWD with:<br />
*** stuff from CSS3 UI that only had one implementation (that we believe is worthy of standardizing, or at least one other implementer expresses interest on)<br />
*** forward reaching properties/values to enable native-like interfaces<br />
* collect/address new CSS3 UI LCWD issues as they are reported<br />
** respond to all the commenters on issues with proposed resolutions (hopefully thus addressing their concerns and resolving the issues accordingly)<br />
** incrementally draft new CSS3-UI CR draft accordingly<br />
* wait for new CSS3 UI LCWD last-call period to end<br />
* write UI Selectors LCWD - with features with at least one implementation, any with less than 2 implementations, mark at risk.<br />
* edit CSS3-UI CR draft accordingly that is ready for PR<br />
* WG processes for taking it to PR<br />
* draft CSS3.1-UI/CSS4-UI WD with features that we want but didn't make into CSS3-UI<br />
** previous CSS3-UI features that got dropped above<br />
** other CSS features that are UI related in other CSS or other W3C specs<br />
*** :placeholder pseudo-class. related: [https://bugzilla.mozilla.org/show_bug.cgi?id=457801 bug 457801]<br />
*** CSS3 Hyperlink<br />
*** [[HTML5]] inputs/forms features that are presentation related<br />
** new features<br />
*** CSS portions of [[Gecko:FullScreenAPI]], e.g. the new pseudo-classes<br />
<br />
Remaining development tasks (stub/incomplete)<br />
For each of these, figure out who is the right Mozilla developer to work on this and then work with to understand what it will take to get it implemented:<br />
* icon support: http://www.w3.org/TR/css3-ui/#element<br />
** 'icon' property<br />
** 'content:icon' value<br />
* box-sizing prefix drop: https://bugzilla.mozilla.org/show_bug.cgi?id=243412<br />
* ...<br />
<br />
Additional CSS3 UI related features in Mozilla to investigate:<br />
* [https://developer.mozilla.org/en/CSS/-moz-user-focus -moz-user-focus]<br />
<br />
==== CSS3 Backgrounds and Borders ====<br />
http://www.w3.org/TR/css3-background/<br />
<br />
Outstanding UI related issues:<br />
<br />
===== prefix removal from -moz-border-radius =====<br />
<br />
Currently Mozilla's border-radius properties are prefixed with -moz- and the following bugs/issues are preventing us from removing the prefix:<br />
<br />
* '''% values on border-radius.''' There is existing content (themes?) that depend on the legacy moz-border-radius implementation of % values that depend on the % of *width* in both dimensions.<br />
<br />
* '''clipping overflow and replaced elements.''' We don't currently clip overflow hidden and replaced elements (e.g. img, video, canvas) to rounded corners. We need to do to this for a proper/complete implementation that won't risk creating further legacy/backward compat problems.<br />
<br />
Bugzilla bugs:<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=431176 431176] - (border-radius) Tracking bug for remaining issues with CSS3 border-radius<br />
*[https://bugzilla.mozilla.org/show_bug.cgi?id=451134 451134] - change -moz-border-radius* properties to css3-background names<br />
<br />
==== CSS3 Element ====<br />
===== write up moz-element proposal =====<br />
Firefox 4 implements background: -moz-element(#foo); to use element with id foo as the background per http://hacks.mozilla.org/2010/08/mozelement/ <br />
<br />
We're pursuing adding element(#foo) as an "at-risk" feature to the CSS3 Values and Units module.<br />
<br />
Proposal (worked with Tab Atkins)<br />
* http://lists.w3.org/Archives/Public/www-style/2010Aug/0635.html<br />
<br />
Threads:<br />
* [http://lists.w3.org/Archives/Public/www-style/2010Aug/thread.html#msg635 element() 2010-08]<br />
* [http://lists.w3.org/Archives/Public/www-style/2010Sep/thread.html#msg0 element() 2010-09]<br />
<br />
Thoughts:<br />
* CSS image() value - which Tab Atkins is already writing up<br />
* Add both to CSS3 Values and Units as at risk for taking it quickly to CR<br />
** in addition to the calc() work that David Baron is already doing in CSS3 Values and Units<br />
<br />
=== DOM API vendor prefixing ===<br />
==== spec implementation problem statement ====<br />
Problem statement: the '''specification-implementation co-dependency problem'''.<br />
<br />
All standards in development have the challenging seemingly contradictory problems of:<br />
# '''needing some implementation to reality-check''' that the API/protocol/format "works" as intended, or is workable/usable<br />
# '''being stuck with a specific (often buggy) implementation''' once it ships because there's content/pages/apps out there that depend on it.<br />
<br />
There are three areas of the open web app platform that this has been problematic:<br />
# '''CSS'''. In the past, some properties were implemented, either as spec'd (and the spec was buggy), or in a way that made sense but incompatible with the spec (because the spec didn't make sense or was not useful to web authors), and then we got "stuck" with those implementations and were not able to update/fix the spec and the respective properties and/or values. Examples:<br />
## 'clip' property. mis-specified in CSS 2.0. implemented as presumed intended in IE4/Windows etc. but turned out to be buggy. some content started depending on it. we (CSS WG at the time) were unable to really fix it in a way that implementations could change, though [http://www.w3.org/TR/CSS21/visufx.html#clipping CSS 2.1 tries to fix clip].<br />
## 'word-wrap' property. in this case, created/proposed by Microsoft, and [http://msdn.microsoft.com/en-us/library/ms531186.aspx implemented as of IE5.5/Windows ca 2000], we are again, kind of stuck with the particular implementation. [http://www.codingforums.com/archive/index.php/t-2075.html Forum posts as of 2002 were recommending use of the literal word-wrap property]. Though since Microsoft did switch to advocating/supporting a prefixed version '-ms-word-wrap'. Note that it is also [https://developer.mozilla.org/en/CSS/word-wrap supported in Firefox 3.5 ca 2009], and it is in the latest (2007) version of the [http://www.w3.org/TR/2007/WD-css3-text-20070306/#word-wrap CSS3 Text spec which is just a working draft].<br />
### See related 'word-break' property ([http://www.w3.org/TR/2007/WD-css3-text-20070306/#word-break word-break in CSS3 Text WD] - latest, 2007), also [http://msdn.microsoft.com/en-us/library/ms531184.aspx initially (partially) implemented in Internet Explorer 5.x as word-break], and later switched to the prefixed '-ms-word-break'. [http://msdn.microsoft.com/en-us/library/cc351024%28VS.85%29.aspx More on CSS Compatibility and Internet Explorer].<br />
# '''HTML'''. Too many examples to list here. Some browsers are still stuck supporting <code>&lt;blink&gt;</code> and <code>&lt;marquee&gt;</code> (which has many odd details), nevermind the classic example of <code>&lt;table&gt;</code> layout, with tons of odd special cases and error-handling for compat, originally from Netscape's implementation, reverse-engineered by Microsoft in Internet Explorer, which has subsequently been reverse-engineered by every other browser.<br />
# '''DOM'''. In particular [http://www.w3.org/TR/2009/WD-webstorage-20091222/ Web Storage working draft] (e.g. the 'localStorage' attribute/property) was implemented in multiple browsers (IE8+, Chrome, Safari, Opera, Mozilla as of 2010 - date order unknown). By the time people discovered it was not threadsafe as specified, it was too late to change the spec to fix that problem - it would have broken too many apps/sites already written which apparently depended on it.<br />
<br />
==== existing solutions ====<br />
<br />
The only one of these areas of technology that has an explicit solution to the specification-implementation co-dependency problem is CSS, through vendor-prefixes.<br />
<br />
===== CSS vendor prefixes =====<br />
In the early 2000s the participants in the CSS working group agreed to formalize a way for implementors to build experimental implementations of new properties and values which were only in a working draft (not yet in a Candidate Recommendation) without saddling the property with implementation specific bugs that content would end up inadvertently depending on.<br />
<br />
CSS prefixing is fairly straight forward:<br />
<br />
<pre>- abbreviated_vendor_prefix - property_name</pre><br />
<br />
(spaces added for clarification of the different components)<br />
<br />
Examples include:<br />
* -moz-opacity<br />
* -o-border-radius<br />
* -webkit-border-radius<br />
* -ms-word-wrap<br />
<br />
===== CSS vendor prefixes case studies =====<br />
* '''border-radius'''. for a few years now browsers have been implementing ''vendor prefixed'' versions of the border-radius properties, web authors have been experimenting on the web, and the spec has iterated/improved based on feedback. Now we have a well-designed and road-tested 'border-radius' property in a CR spec and implementations are implementing that.<br />
* '''word-wrap vs whitespace: pre-wrap'''. interactions between new properties and new values on existing properties. See this [http://scottonwriting.net/sowBlog/archive/0000/00/00/163005.aspx example of the property vs value interaction] between the new 'word-wrap' property and the (sometimes prefixed) new 'pre-wrap' value on the 'whitespace' property. The point is to show how prefixing can actually work across different approaches to evolving CSS.<br />
<br />
==== analysis of applicability ====<br />
Can we apply similar thinking and solutions to HTML and/or DOM?<br />
<br />
For HTML (or any markup) the thinking is no - because of the fact that an element only allows one tagname, there is no way to have content first use a vendor prefixed tagname (or tagnames from multiple vendors), and then also use a final unprefixed tagname all at the same time as part of a content evolution/transition strategy. CSS vendor prefixing works (as illustrated in the case studies) because authors ''can'' create style sheets that use multiple versions of a property (vendor prefixed and unprefixed) in one style sheet, together while evolving their content over time.<br />
<br />
For DOM, it is not only possible, but there are examples in the wild.<br />
<br />
[https://developer.mozilla.org/en/DOM/window.onmozorientation mozOrientation] is a good example of a vendor prefixed DOM interface implementation. (Note mozOrientation needs to be submitted to a W3C working group for standardization/iteration)<br />
<br />
==== simple DOM vendor prefixes proposal ====<br />
<br />
For all DOM interfaces that are:<br />
* Proprietary. No standards organization draft yet published. OR<br />
* In a W3C working draft, not yet in a Candidate Recommendation.<br />
<br />
Use vendor prefixed interfaces and values as follows:<br />
<br />
<pre>vendor_prefix _ unprefixed_name</pre><br />
<br />
E.g. in the above example of mozOrientation, we really should be using:<br />
<br />
<pre>moz_Orientation</pre><br />
<br />
This works because standard DOM APIs do not use underscores.<br />
<br />
Our goal is to establish a convention (like the above) for all such pre-CR DOM APIs that has the consensus of implementers so that we can avoid creating broken versions of APIs<br />
<br />
=== UI Layout ===<br />
* CSS3 Flex Box<br />
** need to get in touch with Tab Atkins and catch-up on the current state of his work vs. existing prefixed partial implementation in Firefox and Safari.<br />
*** 2010-155 briefly spoke with Tab about flex box in irc and noted that I'm working on css3-color and css3-ui first.<br />
<br />
<br />
== Web Apps Waiting For ==<br />
Tasks which are awaiting follow-ups from various standards bodies/lists. Reping as necessary to keep moving forward.<br />
<br />
=== HTML5 spec improvements ===<br />
A set of tasks/projects for improving the state of the [[HTML5]] specification. Proposals will be moved to separate pages once mature enough for submission to [[standards]] bodies.<br />
<br />
Most of this has been moved to [[HTML5#spec_issues|HTML5: spec issues]].<br />
<br />
==== waiting for HTML5 improvements ====<br />
==== keeping crappy stuff out ====<br />
===== simplify alt attribute guidance =====<br />
Moved to [[HTML5/img#alt_guidance_needs_simplification|HTML5/img]].<br />
===== remove meta Content-Language =====<br />
Moved to [[HTML5/meta#remove_meta_Content-Language|HTML5/meta]]<br />
==== upgrade HTML4 features to be more flexible and usable ====<br />
==== restoring pragmatic HTML4 things ====<br />
Moved to [[HTML5/cite#names_of_speakers|HTML5/cite]].<br />
==== improving new features ====<br />
===== iframe sandbox removal =====<br />
Moved to [[HTML5/iframe#drop_sandbox_attribute|HTML5/iframe]].<br />
===== summary naming =====<br />
Moved to [[HTML5/summary#summary_naming|HTML5/summary]]<br />
===== expand time =====<br />
Moved to [[HTML5/time#expand_time|HTML5/time]]<br />
===== nesting time =====<br />
Moved to [[HTML5/time#nesting_time|HTML5/time]]. am pm handling too.<br />
<br />
==== lower priority improvements ====<br />
* <code>&lt;meter&gt;</code> - poorly named. would prefer something like "gauge" but that's potentially hard(er) to spell. this is a bit bikesheddy though so not a high priority.<br />
<br />
== Social and Identity ==<br />
=== Related Features ===<br />
Features/people working with:<br />
* [[Account Manager]] - Dan Mills<br />
* Mozilla Contacts - Michael Hanson<br />
* Context Menu - Aza Raskin<br />
** see related: 2010-05-03 [http://mozillalabs.com/jetpack/2010/05/03/context-menu-module-microformats/ The Context Menu Module & Microformats] (JetPack)<br />
* ...<br />
<br />
=== Standards and Communities ===<br />
Standards and communities to engage with (recommended, grouped by related)<br />
<br />
identity / profiles / contacts<br />
* [[vCard4]] (IETF vcarddav)<br />
** write up problems with vCard4, divergence from vCard3/hCard/PoCo model, etc.<br />
* [[hCard]] (microformats.org)<br />
* Portable Contacts<br />
* microdata vcard vocab (W3C/WhatWG)<br />
* RelMeAuth<br />
* OpenID<br />
* WebFinger<br />
* ...<br />
<br />
social web<br />
* OAuth (including OAuth 2, xAuth, OWF)<br />
* Activity Streams<br />
* [http://federatedsocialweb.net/ Federated Social Web]<br />
* ...<br />
<br />
== Events ==<br />
[[Events]] I'm planning on participating in accordingly:<br />
* August 23-25 [http://www.w3.org/Style/Group/2010/Oslo W3C CSS WG f2f in Oslo]<br />
* September 1-3 [http://2010.dConstruct.org/ dConstruct in Brighton] - web design and development<br />
* September 21-25 [http://north10.webdirections.org/ Web Directions USA in Atlanta]<br />
<br />
== Web Standards Coordination ==<br />
There are a lot of people at Mozilla working with a variety of different standards bodies. With Arun's recent departure, it's more clear than ever that we need to at least have some sort of a directory of standards organizations (and sub-orgs like working groups) listing who at Mozilla is working with each.<br />
<br />
* [[Standards]] - who is working on what standards in what organizations<br />
<br />
== Reference ==<br />
=== Pages ===<br />
See [[User:Tantek#pages|reference pages created]]<br />
<br />
=== Done ===<br />
Completed tasks, projects, events that have no further related active work items. Will likely move to its own page as it grows, in which case, I'll probably just keep *recently* finished items here and regularly archive them.<br />
<br />
==== Completed Events ====<br />
* June 1-3 Open Source Bridge, Portland, OR, http://opensourcebridge.org<br />
* June 28-30 Voices That Matter Web Design in SF http://www.voicesthatmatter.com/webdesign2010<br />
<br />
* July 6-10 [[Summit2010|Mozilla Summit]] in Whistler, Canada.<br />
<br />
* July 13 [http://www.realestateconnect.com/program/ Real Estate Connect San Francisco] (click on "Workshops »", search for "HTML5") at Hilton San Francisco Union Square, 333 O'Farrell Street, San Francisco, California<br />
** participating in WORKSHOP: ConnectTech / HTML5 Is Coming, Are You Ready?<br />
<br />
* July 17 [http://openwebcamp.org OpenWebCamp II] at Stanford<br />
<br />
* July 18 [http://federatedsocialweb.net/wiki/Main_Page Federated social web summit] ([http://federatedsocialweb.net/wiki/Schedule schedule])<br />
** more info: [http://status.net/2010/06/28/federated-social-web-summit-2010-announced announcement], [http://federatedsocialweb.net/wiki/FedAll2010/Invitations attendees]<br />
<br />
==== Resolved HTML5 improvements and spec issues ====<br />
===== reject longdesc =====<br />
moved to: [[HTML5/img#reject_longdesc|HTML5/img]]<br />
===== allow date only on del ins datetime attribute =====<br />
* moved to [[HTML5/del#datetime_should_take_date|HTML5/del]].</div>Fantasaihttps://wiki.mozilla.org/index.php?title=LandingQueue&diff=245147LandingQueue2010-08-13T02:15:19Z<p>Fantasai: /* Landing Queue for Mozilla-Central */ add 536721</p>
<hr />
<div>= Landing Queue for Mozilla-Central =<br />
<br />
Please add your name to the bottom of the list, the bugs you want to land and what the blocking status of them is. After you push, remove yourself from the top of the list. All pushes should be made after consulting with the tree sheriff. <br />
<br />
*mfinkle ({{nbug|582569}} blocking a fennec a1 blocker - try server shows completely green)<br> <br />
*cpearce+bz ({{nbug|564652}} approval2.0, {{nbug|577607}} approval2.0, {{nbug|569520}} approval2.0, {{nbug|576539}} blocking=final, {{nbug|586535}} blocking=betaN) <br />
*mrbkap {{nbug|583200}} not blocking, {{nbug|584180}} blocking=betaN, {{bug|584512}} blocking=beta4 <br />
*sicking {{nbug|581944}} blocking beta 5. {{nbug|582228}} non-blocking but approved. <br />
*mwu {{nbug|556644}} more omnijar patches. blocking beta 4 <br />
*nthomas {{nbug|576053}} symbols for 64bit mac builds) <br />
*josh: {{nbug|586713}} blocking, {{nbug|584965}} blocking, {{nbug|578868}} blocking <br />
*bmilligan/jst: {{nbug|193911}}, a=jst, cache size change, very badly needed.<br />
*benwa: {{nbug|577494}} betaN+, {{nbug|583356}} beta4+.<br />
*fantasai {{nbug|536721} final+ approval2.0+<br />
<br />
<!-- previous queue, mostly asleep right now<br />
* roc<br />
--> <br />
<br />
== Ride-along patches ==<br />
<br />
Add yourself here if you would prefer that some kind soul check your patch in on your behalf. <br />
<br />
*[mailto:neil@parkwaycc.co.uk <strike>Neil Rashbrook</strike>]<strike>{{nbug|586219}} blocking=beta4</strike><br />
*limi/fryn {{bug|565966}} a=beltzner, switch BBN to normal search in location bar</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Tantek-Mozilla-Projects&diff=240872Tantek-Mozilla-Projects2010-07-23T22:55:12Z<p>Fantasai: /* remaining tasks */</p>
<hr />
<div>Hi, I'm [[User:Tantek|Tantek Çelik]], and you've found my list of projects that I'm working on with Mozilla.<br />
<br />
I'm currently (as of 2010-146) a Mozilla contractor working with Chris Blizzard and the web standards team, focused on specification work, especially around web applications user interfaces and social/identity open web technologies.<br />
<br />
In particular:<br />
<br />
== Web Apps ==<br />
=== HTML5 spec improvements ===<br />
A set of tasks/projects for improving the state of the [[HTML5]] specification. Proposals will be moved to separate pages once mature enough for submission to [[standards]] bodies.<br />
<br />
Most of this has been moved to [[HTML5#spec_issues|HTML5: spec issues]].<br />
<br />
==== keeping crappy stuff out ====<br />
===== reject longdesc =====<br />
moved to: [[HTML5/img#reject_longdesc|HTML5/img]]<br />
<br />
===== remove meta Content-Language =====<br />
Moved to [[HTML5/meta#remove_meta_Content-Language|HTML5/meta]]<br />
<br />
===== investigate alt attribute revisions =====<br />
Moved to [[HTML5/img#alt_guidance_needs_simplification|HTML5/img]].<br />
<br />
==== restoring pragmatic HTML4 things ====<br />
Moved to [[HTML5/cite#names_of_speakers|HTML5/cite]].<br />
<br />
==== upgrade HML4 features to be more flexible and usable ====<br />
* moved to [[HTML5/del#datetime_should_take_date|HTML5/del]].<br />
<br />
==== improving new features ====<br />
===== iframe sandbox removal =====<br />
Moved to [[HTML5/iframe#drop_sandbox_attribute|HTML5/iframe]].<br />
<br />
===== summary naming =====<br />
Moved to [[HTML5/summary#summary_naming|HTML5/summary]]<br />
===== expand time =====<br />
Moved to [[HTML5/time#expand_time|HTML5/time]]<br />
===== nesting time =====<br />
Moved to [[HTML5/time#nesting_time|HTML5/time]]<br />
<br />
==== lower priority improvements ====<br />
<br />
* <code>&lt;meter&gt;</code> - poorly named. would prefer something like "gauge" but that's potentially hard(er) to spell. this is a bit bikesheddy though so not a high priority.<br />
<br />
=== DOM API vendor prefixing ===<br />
==== spec implementation problem statement ====<br />
Problem statement: the '''specification-implementation co-dependency problem'''.<br />
<br />
All standards in development have the challenging seemingly contradictory problems of:<br />
# '''needing some implementation to reality-check''' that the API/protocol/format "works" as intended, or is workable/usable<br />
# '''being stuck with a specific (often buggy) implementation''' once it ships because there's content/pages/apps out there that depend on it.<br />
<br />
There are three areas of the open web app platform that this has been problematic:<br />
# '''CSS'''. In the past, some properties were implemented, either as spec'd (and the spec was buggy), or in a way that made sense but incompatible with the spec (because the spec didn't make sense or was not useful to web authors), and then we got "stuck" with those implementations and were not able to update/fix the spec and the respective properties and/or values. Examples:<br />
## 'clip' property. mis-specified in CSS 2.0. implemented as presumed intended in IE4/Windows etc. but turned out to be buggy. some content started depending on it. we (CSS WG at the time) were unable to really fix it in a way that implementations could change, though [http://www.w3.org/TR/CSS21/visufx.html#clipping CSS 2.1 tries to fix clip].<br />
## 'word-wrap' property. in this case, created/proposed by Microsoft, and [http://msdn.microsoft.com/en-us/library/ms531186.aspx implemented as of IE5.5/Windows ca 2000], we are again, kind of stuck with the particular implementation. [http://www.codingforums.com/archive/index.php/t-2075.html Forum posts as of 2002 were recommending use of the literal word-wrap property]. Though since Microsoft did switch to advocating/supporting a prefixed version '-ms-word-wrap'. Note that it is also [https://developer.mozilla.org/en/CSS/word-wrap supported in Firefox 3.5 ca 2009], and it is in the latest (2007) version of the [http://www.w3.org/TR/2007/WD-css3-text-20070306/#word-wrap CSS3 Text spec which is just a working draft].<br />
### See related 'word-break' property ([http://www.w3.org/TR/2007/WD-css3-text-20070306/#word-break word-break in CSS3 Text WD] - latest, 2007), also [http://msdn.microsoft.com/en-us/library/ms531184.aspx initially (partially) implemented in Internet Explorer 5.x as word-break], and later switched to the prefixed '-ms-word-break'. [http://msdn.microsoft.com/en-us/library/cc351024%28VS.85%29.aspx More on CSS Compatibility and Internet Explorer].<br />
# '''HTML'''. Too many examples to list here. Some browsers are still stuck supporting <code>&lt;blink&gt;</code> and <code>&lt;marquee&gt;</code> (which has many odd details), nevermind the classic example of <code>&lt;table&gt;</code> layout, with tons of odd special cases and error-handling for compat, originally from Netscape's implementation, reverse-engineered by Microsoft in Internet Explorer, which has subsequently been reverse-engineered by every other browser.<br />
# '''DOM'''. In particular [http://www.w3.org/TR/2009/WD-webstorage-20091222/ Web Storage working draft] (e.g. the 'localStorage' attribute/property) was implemented in multiple browsers (IE8+, Chrome, Safari, Opera, Mozilla as of 2010 - date order unknown). By the time people discovered it was not threadsafe as specified, it was too late to change the spec to fix that problem - it would have broken too many apps/sites already written which apparently depended on it.<br />
<br />
==== existing solutions ====<br />
<br />
The only one of these areas of technology that has an explicit solution to the specification-implementation co-dependency problem is CSS, through vendor-prefixes.<br />
<br />
===== CSS vendor prefixes =====<br />
In the early 2000s the participants in the CSS working group agreed to formalize a way for implementors to build experimental implementations of new properties and values which were only in a working draft (not yet in a Candidate Recommendation) without saddling the property with implementation specific bugs that content would end up inadvertently depending on.<br />
<br />
CSS prefixing is fairly straight forward:<br />
<br />
<pre>- abbreviated_vendor_prefix - property_name</pre><br />
<br />
(spaces added for clarification of the different components)<br />
<br />
Examples include:<br />
* -moz-opacity<br />
* -o-border-radius<br />
* -webkit-border-radius<br />
* -ms-word-wrap<br />
<br />
===== CSS vendor prefixes case studies =====<br />
* '''border-radius'''. for a few years now browsers have been implementing ''vendor prefixed'' versions of the border-radius properties, web authors have been experimenting on the web, and the spec has iterated/improved based on feedback. Now we have a well-designed and road-tested 'border-radius' property in a CR spec and implementations are implementing that.<br />
* '''word-wrap vs whitespace: pre-wrap'''. interactions between new properties and new values on existing properties. See this [http://scottonwriting.net/sowBlog/archive/0000/00/00/163005.aspx example of the property vs value interaction] between the new 'word-wrap' property and the (sometimes prefixed) new 'pre-wrap' value on the 'whitespace' property. The point is to show how prefixing can actually work across different approaches to evolving CSS.<br />
<br />
==== analysis of applicability ====<br />
Can we apply similar thinking and solutions to HTML and/or DOM?<br />
<br />
For HTML (or any markup) the thinking is no - because of the fact that an element only allows one tagname, there is no way to have content first use a vendor prefixed tagname (or tagnames from multiple vendors), and then also use a final unprefixed tagname all at the same time as part of a content evolution/transition strategy. CSS vendor prefixing works (as illustrated in the case studies) because authors ''can'' create style sheets that use multiple versions of a property (vendor prefixed and unprefixed) in one style sheet, together while evolving their content over time.<br />
<br />
For DOM, it is not only possible, but there are examples in the wild.<br />
<br />
[https://developer.mozilla.org/en/DOM/window.onmozorientation mozOrientation] is a good example of a vendor prefixed DOM interface implementation. (Note mozOrientation needs to be submitted to a W3C working group for standardization/iteration)<br />
<br />
==== simple DOM vendor prefixes proposal ====<br />
<br />
For all DOM interfaces that are:<br />
* Proprietary. No standards organization draft yet published. OR<br />
* In a W3C working draft, not yet in a Candidate Recommendation.<br />
<br />
Use vendor prefixed interfaces and values as follows:<br />
<br />
<pre>vendor_prefix _ unprefixed_name</pre><br />
<br />
E.g. in the above example of mozOrientation, we really should be using:<br />
<br />
<pre>moz_Orientation</pre><br />
<br />
This works because standard DOM APIs do not use underscores.<br />
<br />
Our goal is to establish a convention (like the above) for all such pre-CR DOM APIs that has the consensus of implementers so that we can avoid creating broken versions of APIs<br />
<br />
=== UI Styling ===<br />
At a high level there are two general clusters of use cases that web pages/apps want/need to solve in terms of user interface fidelity.<br />
<br />
'''1. Beautiful Built-in Tweakable Controls.''' Pages that have some interactivity where the designer wants to use the built-in set of semantic user interface controls/inputs as long as they can just "tweak" them to match their web page/site design, e.g. color, background, typography. As long as the look and feel of built-in controls is beautiful enough both by default and with minor tweaks, then the hypothesis is that web designers will be happy/content to use built-in controls rather than go the extra mile to re-build custom controls with divs and javascript etc.<br />
<br />
Some data for this hypothesis: default iPhone/iPad controls are pretty enough that most developers are more than happy to use them - the default controls make their apps look beautiful, polished, without much work/tweaking (modulo layout/sizing etc.) If we can achieve that same experience with built-in controls, the theory is that most web designers will be happy to stick with built-in controls + CSS.<br />
<br />
'''2. Rich native-app-like experiences.''' Games. Media interfaces like WinAmp. There are always going to be some user interfaces where the developer wants nearly total control of the look and feel. Just take a look at typical Flash or Flex app UIs (note: some of those are egregiously inconsistent with the underlying OS platform just for the sake of being different - hard to avoid that but we can discourage it by making the cluster 1 solution easier and more accessible). In this case I'd like to see us figure out how to build hybrid controls that:<br />
<br />
a) Are built with the closest semantic built-in control for any particular custom control, <em>and</em><br />
<br />
b) Use a &lt;canvas&gt; for drawing custom appearance, with DOM event handlers drawing control-specific state in the canvas, <em>and</em><br />
<br />
c) Have text-based fall-back in the canvas.<br />
<br />
Example markup (event attributes/handlers omitted for simplicity)<br />
<br />
<pre>&lt;button&gt;&lt;canvas&gt; Play &lt;/canvas&gt;&lt;/button&gt;</pre><br />
<br />
(Now we just need a way to do that with text inputs too.)<br />
<br />
The goal in this second scenario is to enable building rich native-app-like user interfaces where the path of least resistance to building it uses building blocks that in themselves enable accessibility. I think this is both possible, and is a necessary course of action to avoid having to do "bolt-on" accessibility later.<br />
<br />
<br />
For now, the sections below focus on addressing/solving the first cluster of use cases first.<br />
<br />
The theory is that by addressing that first that it will become more obvious which specific real-world rich interfaces fall into the second cluster, and therefore we can design for that second cluster based on those specific interfaces.<br />
<br />
==== Styling HTML5 UI elements ====<br />
We need to define how Forms and other UI elements can be styled, and to synchronize our work with the W3C.<br />
<br />
Working with Mounir Lamouri on this: [[User:Mounir.lamouri/HTML5_Forms]]<br />
<br />
Each [[HTML5]] UI element must be complete to the following criteria:<br />
<br />
1. It must include pleasant and working UI, where appropriate.<br />
<br />
This is a big design challenge. Take a look at what Opera has done for example (in terms of challenges). Here is a simple test page which shows default renderings - compare in various browsers and try interacting with the new widgets especially in Opera:<br />
<br />
http://tantek.com/new-inputs.html<br />
<br />
See [[HTML5/input]] for more &lt;input&gt; element tests.<br />
<br />
* Need more sample/test/wiki pages for other HTML5 UI elements.<br />
<br />
2. You must be able to use CSS to style the element, especially the UI that we generate. This includes any pre-defined pseudo-selectors (invalid, required, icon, etc.)<br />
<br />
Agreed, this is an absolute requirement.<br />
<br />
Whenever there is ''any'' custom appearance of a form control, e.g. based on the new types, designers ''must'' be able to restyle them to fit in with their design. This means at a minimum:<br />
* ability to select specific "pieces" of any compound/composite form control for styling<br />
** feeds into requirements for CSS pseudo-elements<br />
** consider existing [http://www.w3.org/TR/css3-ui/#pseudo-elements CSS3-UI pseudo-elements]<br />
*** ::value can be used for selecting/styling placeholder text (see [https://bugzilla.mozilla.org/show_bug.cgi?id=457801#c25 bug 457801 comment 25])<br />
*** ::choices <br />
*** ::repeat-item <br />
*** ::repeat-index<br />
** consider additional pseudo-elements based on vendor prefixed pseudos<br />
*** Safari 5 supports pseudo-elements for restyling overflow scrollbars<br />
**** ::webkit-scrollbar-thumb<br />
**** ::webkit-scrollbar-track<br />
**** ::webkit-scrollbar<br />
* ability to select specific "states" of any form control (may require ability to select states of specific pieces as well - that will be a challenge though as pseudo-elements themselves cannot have pseudo-classes in CSS)<br />
** existing [http://www.w3.org/TR/css3-selectors/#UIstates Selectors UI pseudo-classes], and some notes on [http://www.w3.org/TR/html5/interactive-elements.html#pseudo-classes how HTML5 DOM property states trigger these pseudo-classes]<br />
*** :hover :active - based on mouse/pointer interactions. the challenge here is to find alternatives for touch based interfaces.<br />
*** :focus - an element which is currently accepting keyboard, pointer, or other input device events.<br />
*** :enabled and :disabled - based on the state of the "disabled" property on the element.<br />
*** :checked - based on the "checked" property on input types "radio" and "checkbox", and also on the "selected" property on option element.<br />
*** :indeterminate - based on the "indeterminate" property of the input types "radio" and "checkbox".<br />
*** :default - [http://www.w3.org/TR/html5/interactive-elements.html#selector-default default buttons or submit buttons]<br />
*** :valid and :invalid - input elements that are candidates for constraint validation and either do or don't (respectively) satisfy their constraints.<br />
*** :in-range and :out-of-range - input elements that are candidates for constraint validation and that are neither under nor overflowing (for :in-range) or either under/overflowing (for :out-of-range).<br />
*** :required and :optional - [http://www.w3.org/TR/html5/interactive-elements.html#selector-required see HTML5 description of being required / required attribute]<br />
*** :read-only and :read-write - [http://www.w3.org/TR/html5/interactive-elements.html#selector-read-only see HTML5 description of read-only vs read-write elements].<br />
** additional pseudo-selectors as needed for states/portions included in HTML5 forms elements features<br />
*** "placeholder" attribute - needs a new :-moz-placeholder pseudo-class ([https://bugzilla.mozilla.org/show_bug.cgi?id=457801 bug 457801])<br />
**** :placeholder pseudo-class needs to be proposed for CSS3.1 UI/Selectors.<br />
* typography<br />
** font properties<br />
** text properties<br />
** color<br />
* box properties<br />
** width<br />
** height<br />
** padding<br />
** border<br />
** margin<br />
** background<br />
** box-shadow<br />
<br />
<br />
3. If there's a constraint API the API must be complete.<br />
<br />
4. It should be [[Accessibility/HTML5_Forms|fully accessible]].<br />
<br />
==== Possible new HTML5 UI elements ====<br />
The new user interface elements in HTML5 cover quite a bit of Web Apps UI scenarios. There are both requests based on specific user/application scenarios, and there is also the full set of user interface objects represented by the values of the CSS3 UI 'appearance' property<br />
===== specific new elements =====<br />
* <code>&lt;menubar&gt;</code><br />
* pull-down-menu<br />
* context-menu<br />
* <code>&lt;input type="year"&gt;</code> - based on <code>&lt;time&gt;</code> element use case research<br />
* <code>&lt;input type="month-day"&gt;</code> - based on <code>&lt;time&gt;</code> element use case research<br />
<br />
===== CSS3 UI appearance values =====<br />
From [http://www.w3.org/TR/css3-ui/#appearance-val CSS3 UI 5.1. Appearance values]:<br />
<br />
Needs:<br />
* tab - a button that looks like the browser's tabbed windows tabs.<br />
* menubar - a menu of menus, typically arranged linearly, in a horizontal bar. <br />
* pull-down-menu - a menu where the name of the menu is displayed and the options remain hidden until the user activates the menu. When the user releases or deactivates the menu, the options are hidden again.<br />
* radio-group - a menu where the options are displayed as radio-buttons.<br />
* checkbox-group - a menu where the options are displayed as checkboxes. <br />
* outline-tree - a menu where the options can be shown or hidden with small widgets, often represented by a small triangle or plus and minus signs. might be possible to build one using <code>&lt;details&gt;</code> and <code>&lt;summary&gt;</code>.<br />
* combo-box - a field which is accompanied by a menu of preset values that can be used to quickly enter common or typical values. <br />
* signature - a field for entering a signature. <br />
<br />
Full list with equivalents:<br />
* icon - handled by 'icon' property and HTML5 Drag &amp; Drop<br />
* window - mostly handled outside of elements, except perhaps 'tooltip' which could be purely presentational<br />
* button - by default a push-button<br />
** push-button - <code>&lt;input type=button&gt;<code> and <code>&lt;button&gt;</code><br />
** hyperlink - <code>&lt;a href&gt;</code><br />
** radio-button - <code>&lt;input type="radio"&gt;</code><br />
** checkbox - <code>&lt;input type="checkbox"&gt;</code><br />
** menu-item - <code>&lt;option&gt;</code> and <code>&lt;optgroup&gt;</code><br />
** tab - no HTML5 equivalent<br />
* menu - by default a pop-up-menu<br />
** menubar - no HTML5 equivalent<br />
** pull-down-menu - no HTML5 equivalent<br />
** pop-up-menu - <code>&lt;select&gt;</code><br />
** list-menu - <code>&lt;select size=n</code> (where n>1)<br />
** radio-group - no HTML5 equivalent<br />
** checkbox-group - no HTML5 equivalent<br />
** outline-tree - no complete HTML5 equivalent but <code>&lt;details&gt;</code> and <code>&lt;summary&gt;</code> may help.<br />
** range - <code>&lt;input type="range"&gt;</code><br />
* field - <code>&lt;input type="text"&gt;</code> and <code>&lt;textarea&gt;</code><br />
** combo-box - no HTML5 equivalent<br />
** signature - no HTML5 equivalent<br />
** password - <code>&lt;input type="password"&gt;</code><br />
<br />
==== CSS3 Color ====<br />
;latest published draft<br />
:http://www.w3.org/TR/css3-color/<br />
;latest development / in progress draft<br />
:http://dev.w3.org/csswg/css3-color/<br />
;spec source (for editing)<br />
:http://dev.w3.org/csswg/css3-color/Overview.src.html<br />
;test suite<br />
:http://www.w3.org/Style/CSS/Test/CSS3/Color/20080721/<br />
;implementation reports of the test suite<br />
:http://www.w3.org/Style/CSS/Test/CSS3/Color/current/reports/<br />
;issues list for the current last call<br />
:http://wiki.csswg.org/spec/css3-color - once these issues are addressed, it should be ready to go to PR.<br />
<br />
===== remaining tasks =====<br />
Remaining tasks to get CSS3 Color to PR:<br />
* resolve any remaining open issues in the issues list<br />
* respond to all the commenters in the issues list with proposed resolutions (hopefully thus addressing their concerns and resolving the issues accordingly)<br />
** update the disposition of comments accordingly with responses<br />
* do the remaining editing on the draft<br />
** one of them has an action on Chris Lilley to write text<br />
** ...<br />
* reconfirm that any/all dependent specs are in CR (or later)<br />
* collect new features for CSS3.1/4 Color<br />
** follow-up on color management properties for css3-color that were discussed at 2009 November TPAC CSS f2f (but later punted from css3-color to a future version).<br />
*** check minutes from that meeting for details on conclusions of the property (name, values etc.)<br />
*** contact Beth regarding level of implementation interest, plan to move forward with putting the color management property into a post-css3 working draft of the Color Module<br />
* write a first working draft of CSS3.1/4 Color with collected feature(s) (even if it includes just a new color management property)<br />
* find out where Hixie's tests went (was at http://test.csswg.org/source/contributors/hixie/incoming/css3-color/ ) and figure out what to do with them.<br />
<br />
==== CSS3 UI ====<br />
;latest published draft<br />
:http://www.w3.org/TR/css3-ui/<br />
;latest development / in progress draft<br />
:currently: http://www.w3.org/Style/Group/css3-src/css3-ui/Overview.html<br />
:eventually: <nowiki>http://dev.w3.org/csswg/css3-ui/</nowiki><br />
;spec source (for editing)<br />
:currently: http://www.w3.org/Style/Group/css3-src/css3-ui/Overview.src.html<br />
:eventually: <nowiki>http://dev.w3.org/csswg/css3-ui/Overview.src.html</nowiki><br />
;test suite<br />
:TBD<br />
;implementation reports of the test suite<br />
:TBD<br />
;issues list for the current draft<br />
:http://wiki.csswg.org/spec/css3-ui<br />
<br />
===== remaining tasks =====<br />
Remaining tasks to get CSS3 UI to PR:<br />
<br />
* add '''pointer-events''' A way of specifying whether an element is opaque to pointer events (and receives them) or is transparent to them (letting them get handled by what's underneath.<br />
** https://developer.mozilla.org/en/css/pointer-events - Mozilla spec<br />
*** shipped in Firefox 3.6 - demo: http://demos.hacks.mozilla.org/openweb/pointer-events/<br />
** http://webkit.org/specs/PointerEventsProperty.html - Webkit spec<br />
*** shipped in Safari 4.0<br />
** related: [[SVG:Pointer-events]]<br />
<br />
* consider incorporating '''overflow-x''' and '''overflow-y'''<br />
** pull-in the entirety of section 16 from<br />
*** http://www.w3.org/Style/Group/css3-src/css3-box/#overflow<br />
** sync (incorporated) any updates/changes in 2.1:<br />
*** http://www.w3.org/Style/Group/css2-src/visufx.html#overflow<br />
** search www-style for issues related to 'overflow-x' and 'overflow-y'<br />
*** ask Anne van Kesteren and www-style directly<br />
** check that css3-marquee implicitly deals with overflow-x and overflow-y correctly<br />
*** http://www.w3.org/TR/css3-marquee/#the-overflow-style<br />
** investigate discussion of ink overflow vs layout overflow - [[User:Fantasai|fantasai]] will get more info on this. e.g. box-shadow should never trigger scrollbars. do margins? maybe they don't trigger overflow but if there is overflow anyways (something else triggers scrollbars), then margins influence the dimensions of the scrollable area.<br />
<br />
* document claims of existing implementations<br />
** Webkit CSS3 UI - http://lists.w3.org/Archives/Public/public-html/2009Sep/0060.html<br />
** Opera CSS3 UI - http://lists.w3.org/Archives/Public/public-html/2009Sep/0202.html<br />
** Mozilla CSS3 UI - ???<br />
<br />
* draft and publish at least a minimal coverage test suite that covers those claims<br />
<br />
* document actual implementation results<br />
<br />
* reducing feature set down to what's been implemented in more than one browser<br />
** produce a new CSS3 UI LCWD with only non-at-risk features based on above implementation evidence (or imminent implementation)<br />
** while figuring out what we (CSS WG) would want to move / keep for a CSS3.1/4 UI module - perhaps start that draft.<br />
* collect/address new CSS3 UI LCWD issues as they are reported<br />
** respond to all the commenters on issues with proposed resolutions (hopefully thus addressing their concerns and resolving the issues accordingly)<br />
** incrementally draft new CSS3-UI CR draft accordingly<br />
* wait for new CSS3 UI LCWD last-call period to end<br />
* edit CSS3-UI CR draft accordingly that is ready for PR<br />
* WG processes for taking it to PR<br />
<br />
Remaining development tasks (stub/incomplete)<br />
For each of these, figure out who is the right Mozilla developer to work on this and then work with to understand what it will take to get it implemented:<br />
* icon support: http://www.w3.org/TR/css3-ui/#element<br />
** 'icon' property<br />
** 'content:icon' value<br />
* box-sizing prefix drop: https://bugzilla.mozilla.org/show_bug.cgi?id=243412<br />
* ...<br />
<br />
=== UI Layout ===<br />
* CSS3 Flex Box<br />
** need to get in touch with Tab Atkins and catch-up on the current state of his work vs. existing prefixed partial implementation in Firefox and Safari.<br />
*** 2010-155 briefly spoke with Tab about flex box in irc and noted that I'm working on css3-color and css3-ui first.<br />
<br />
== Social and Identity ==<br />
=== Related Features ===<br />
Features to work with:<br />
* Accounts Manager<br />
* ...<br />
=== Standards and Communities ===<br />
Standards and communities to engage with (recommended, unprioritized)<br />
* vCard 4 (IETF vcarddav)<br />
* hCard (microformats.org)<br />
* microdata vcard vocab (W3C/WhatWG)<br />
* OAuth (including OAuth 2, xAuth, OWF)<br />
* Portable Contacts<br />
* RelMeAuth<br />
* OpenID<br />
* WebFinger<br />
* Activity Streams<br />
* ...<br />
<br />
== Events ==<br />
[[Events]] I'm planning on participating in accordingly:<br />
* August 23-25 [http://www.w3.org/Style/Group/2010/Oslo W3C CSS WG f2f in Oslo]<br />
* September 1-3 [http://2010.dConstruct.org/ dConstruct in Brighton] - web design and development<br />
<br />
== Web Standards Coordination ==<br />
There are a lot of people at Mozilla working with a variety of different standards bodies. With Arun's recent departure, it's more clear than ever that we need to at least have some sort of a directory of standards organizations (and sub-orgs like working groups) listing who at Mozilla is working with each.<br />
<br />
* [[Standards]] - who is working on what standards in what organizations<br />
<br />
== Reference ==<br />
=== Pages ===<br />
Reference pages created:<br />
* [[CSS3]]<br />
** [[CSS3/color|color module]]<br />
** [[CSS3/ui|ui module]]<br />
* [[HTML5]]<br />
** [[HTML5/canvas|&lt;canvas&gt;]]<br />
** [[HTML5/input|&lt;input&gt;]]<br />
<br />
=== Done ===<br />
Completed tasks, projects, events that have no further related active work items. Will likely move to its own page as it grows, in which case, I'll probably just keep *recently* finished items here and regularly archive them.<br />
<br />
* June 1-3 Open Source Bridge, Portland, OR, http://opensourcebridge.org<br />
* June 28-30 Voices That Matter Web Design in SF http://www.voicesthatmatter.com/webdesign2010<br />
<br />
* July 6-10 [[Summit2010|Mozilla Summit]] in Whistler, Canada.<br />
<br />
* July 13 [http://www.realestateconnect.com/program/ Real Estate Connect San Francisco] (click on "Workshops »", search for "HTML5") at Hilton San Francisco Union Square, 333 O'Farrell Street, San Francisco, California<br />
** participating in WORKSHOP: ConnectTech / HTML5 Is Coming, Are You Ready?<br />
<br />
* July 17 [http://openwebcamp.org OpenWebCamp II] at Stanford<br />
<br />
* July 18 [http://federatedsocialweb.net/wiki/Main_Page Federated social web summit] ([http://federatedsocialweb.net/wiki/Schedule schedule])<br />
** more info: [http://status.net/2010/06/28/federated-social-web-summit-2010-announced announcement], [http://federatedsocialweb.net/wiki/FedAll2010/Invitations attendees]</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Standards&diff=237124Standards2010-07-09T08:20:01Z<p>Fantasai: /* CSS WG */</p>
<hr />
<div>{{stub}}<br />
<br />
<h1> Web Standards Coordination </h1><br />
<br />
There are a lot of people at Mozilla working with a variety of different standards bodies. With Arun's recent departure, it's more clear than ever that we need to at least have some sort of a directory of standards organizations (and sub-orgs like working groups) listing who at Mozilla is working with each.<br />
<br />
Organized by standards body, then working group (if any), then list of Mozilla folks participating in that working group, optionally listing which particular specifications (or sections thereof) that they edit/author/contribute to.<br />
<br />
If you actively communicate/participate with a standards body, please add yourself!<br />
<br />
If you work in multiple working groups or with multiple standards organizations, list yourself in each, linking to your wiki User page.<br />
<br />
For standards development/implementation see and add to: [[Standards implementation]]<br />
<br />
= IETF =<br />
http://ietf.org/<br />
* Rob Sayre<br />
* ...<br />
<br />
Specifications: ...<br />
<br />
= OWF =<br />
http://openwebfoundation.org/<br />
* [[User:Tantek|Tantek Çelik]] (elected board member)<br />
<br />
Specifications: [http://openwebfoundation.org/legal/agreement/ Open Web Foundation Agreement] (OWFa)<br />
<br />
= W3C =<br />
http://w3.org/<br />
== AC ==<br />
* David Baron<br />
== CSS WG ==<br />
http://w3.org/Style/CSS/<br />
* David Baron<br />
* [[User:Tantek|Tantek Çelik]]<br />
* [[User:Fantasai|fantasai]]<br />
* Henri Sivonen<br />
* Boris Zbarsky<br />
* John Daggett<br />
* ...<br />
<br />
Specifications: [[CSS21]], [[CSS3]]<br />
<br />
== HTML WG ==<br />
http://w3.org/MarkUp/<br />
* [[User:Tantek|Tantek Çelik]]<br />
* Jonas Sicking<br />
* Henri Sivonen<br />
* ...<br />
<br />
Specifications: [[HTML5]]<br />
<br />
== Internationalization WG ==<br />
http://w3.org/International/<br />
* [[User:Fantasai|fantasai]]<br />
<br />
== SVG WG ==<br />
http://w3.org/SVG/<br />
* ... User: ...<br />
<br />
Specifications: ...<br />
<br />
== Web Apps WG ==<br />
* ... User: ...<br />
<br />
Specifications: ...</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Standards&diff=237123Standards2010-07-09T08:19:08Z<p>Fantasai: /* i18n WG */</p>
<hr />
<div>{{stub}}<br />
<br />
<h1> Web Standards Coordination </h1><br />
<br />
There are a lot of people at Mozilla working with a variety of different standards bodies. With Arun's recent departure, it's more clear than ever that we need to at least have some sort of a directory of standards organizations (and sub-orgs like working groups) listing who at Mozilla is working with each.<br />
<br />
Organized by standards body, then working group (if any), then list of Mozilla folks participating in that working group, optionally listing which particular specifications (or sections thereof) that they edit/author/contribute to.<br />
<br />
If you actively communicate/participate with a standards body, please add yourself!<br />
<br />
If you work in multiple working groups or with multiple standards organizations, list yourself in each, linking to your wiki User page.<br />
<br />
For standards development/implementation see and add to: [[Standards implementation]]<br />
<br />
= IETF =<br />
http://ietf.org/<br />
* Rob Sayre<br />
* ...<br />
<br />
Specifications: ...<br />
<br />
= OWF =<br />
http://openwebfoundation.org/<br />
* [[User:Tantek|Tantek Çelik]] (elected board member)<br />
<br />
Specifications: [http://openwebfoundation.org/legal/agreement/ Open Web Foundation Agreement] (OWFa)<br />
<br />
= W3C =<br />
http://w3.org/<br />
== AC ==<br />
* David Baron<br />
== CSS WG ==<br />
http://w3.org/Style/CSS/<br />
* David Baron<br />
* [[User:Tantek|Tantek Çelik]]<br />
* fantasai<br />
* Henri Sivonen<br />
* Boris Zbarsky<br />
* John Daggett<br />
* ...<br />
<br />
Specifications: [[CSS21]], [[CSS3]]<br />
<br />
== HTML WG ==<br />
http://w3.org/MarkUp/<br />
* [[User:Tantek|Tantek Çelik]]<br />
* Jonas Sicking<br />
* Henri Sivonen<br />
* ...<br />
<br />
Specifications: [[HTML5]]<br />
<br />
== Internationalization WG ==<br />
http://w3.org/International/<br />
* [[User:Fantasai|fantasai]]<br />
<br />
== SVG WG ==<br />
http://w3.org/SVG/<br />
* ... User: ...<br />
<br />
Specifications: ...<br />
<br />
== Web Apps WG ==<br />
* ... User: ...<br />
<br />
Specifications: ...</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Tantek-Mozilla-Projects&diff=229892Tantek-Mozilla-Projects2010-06-10T22:17:44Z<p>Fantasai: /* remaining tasks */</p>
<hr />
<div>Hi, I'm [[User:Tantek|Tantek Çelik]], and you've found my list of projects that I'm working on with Mozilla.<br />
<br />
I'm currently (as of 2010-146) a Mozilla contractor working with Chris Blizzard, Arun Ranganathan, and the web standards team, focused on specification work, especially around web applications user interfaces and social/identity open web technologies.<br />
<br />
In particular:<br />
<br />
== Web Apps ==<br />
=== UI Styling ===<br />
At a high level there are two general clusters of use cases that web pages/apps want/need to solve in terms of user interface fidelity.<br />
<br />
'''1. Beautiful Built-in Tweakable Controls.''' Pages that have some interactivity where the designer wants to use the built-in set of semantic user interface controls/inputs as long as they can just "tweak" them to match their web page/site design, e.g. color, background, typography. As long as the look and feel of built-in controls is beautiful enough both by default and with minor tweaks, then the hypothesis is that web designers will be happy/content to use built-in controls rather than go the extra mile to re-build custom controls with divs and javascript etc.<br />
<br />
Some data for this hypothesis: default iPhone/iPad controls are pretty enough that most developers are more than happy to use them - the default controls make their apps look beautiful, polished, without much work/tweaking (modulo layout/sizing etc.) If we can achieve that same experience with built-in controls, the theory is that most web designers will be happy to stick with built-in controls + CSS.<br />
<br />
'''2. Rich native-app-like experiences.''' Games. Media interfaces like WinAmp. There are always going to be some user interfaces where the developer wants nearly total control of the look and feel. Just take a look at typical Flash or Flex app UIs (note: some of those are egregiously inconsistent with the underlying OS platform just for the sake of being different - hard to avoid that but we can discourage it by making the cluster 1 solution easier and more accessible). In this case I'd like to see us figure out how to build hybrid controls that:<br />
<br />
a) Are built with the closest semantic built-in control for any particular custom control, <em>and</em><br />
<br />
b) Use a &lt;canvas&gt; for drawing custom appearance, with DOM event handlers drawing control-specific state in the canvas, <em>and</em><br />
<br />
c) Have text-based fall-back in the canvas.<br />
<br />
Example markup (event attributes/handlers omitted for simplicity)<br />
<br />
<pre>&lt;button&gt;&lt;canvas&gt; Play &lt;/canvas&gt;&lt;/button&gt;</pre><br />
<br />
(Now we just need a way to do that with text inputs too.)<br />
<br />
The goal in this second scenario is to enable building rich native-app-like user interfaces where the path of least resistance to building it uses building blocks that in themselves enable accessibility. I think this is both possible, and is a necessary course of action to avoid having to do "bolt-on" accessibility later.<br />
<br />
<br />
For now, the sections below focus on addressing/solving the first cluster of use cases first.<br />
<br />
The theory is that by addressing that first that it will become more obvious which specific real-world rich interfaces fall into the second cluster, and therefore we can design for that second cluster based on those specific interfaces.<br />
<br />
==== Styling HTML5 forms elements ====<br />
We need to define how Forms must be styled, and to synchronize our work with the W3C.<br />
<br />
Working with Mounir Lamouri on this: [[User:Mounir.lamouri/HTML5_Forms]]<br />
<br />
Each [[HTML5]] form element must be complete to the following criteria:<br />
<br />
1. It must include pleasant and working UI, where appropriate.<br />
<br />
This is a big design challenge. Take a look at what Opera has done for example (in terms of challenges). Here is a simple test page which shows default renderings - compare in various browsers and try interacting with the new widgets especially in Opera:<br />
<br />
http://tantek.com/new-inputs.html<br />
<br />
See [[HTML5/input]] for more &lt;input&gt; element tests.<br />
<br />
2. You must be able to use CSS to style the element, especially the UI that we generate. This includes any pre-defined pseudo-selectors (invalid, required, icon, etc.)<br />
<br />
Agreed, this is an absolute requirement.<br />
<br />
Whenever there is ''any'' custom appearance of a form control, e.g. based on the new types, designers ''must'' be able to restyle them to fit in with their design. This means at a minimum:<br />
* ability to select specific "pieces" of any compound/composite form control for styling<br />
** feeds into requirements for CSS pseudo-elements<br />
** consider existing [http://www.w3.org/TR/css3-ui/#pseudo-elements CSS3-UI pseudo-elements]<br />
*** ::value can be used for selecting/styling placeholder text (see [https://bugzilla.mozilla.org/show_bug.cgi?id=457801#c25 bug 457801 comment 25])<br />
*** ::choices <br />
*** ::repeat-item <br />
*** ::repeat-index<br />
* ability to select specific "states" of any form control (may require ability to select states of specific pieces as well - that will be a challenge though as pseudo-elements themselves cannot have pseudo-classes in CSS)<br />
** existing [http://www.w3.org/TR/css3-selectors/#UIstates Selectors UI pseudo-classes], and some notes on [http://www.w3.org/TR/html5/interactive-elements.html#pseudo-classes how HTML5 DOM property states trigger these pseudo-classes]<br />
*** :hover :active - based on mouse/pointer interactions. the challenge here is to find alternatives for touch based interfaces.<br />
*** :focus - an element which is currently accepting keyboard, pointer, or other input device events.<br />
*** :enabled and :disabled - based on the state of the "disabled" property on the element.<br />
*** :checked - based on the "checked" property on input types "radio" and "checkbox", and also on the "selected" property on option element.<br />
*** :indeterminate - based on the "indeterminate" property of the input types "radio" and "checkbox".<br />
*** :default - [http://www.w3.org/TR/html5/interactive-elements.html#selector-default default buttons or submit buttons]<br />
*** :valid and :invalid - input elements that are candidates for constraint validation and either do or don't (respectively) satisfy their constraints.<br />
*** :in-range and :out-of-range - input elements that are candidates for constraint validation and that are neither under nor overflowing (for :in-range) or either under/overflowing (for :out-of-range).<br />
*** :required and :optional - [http://www.w3.org/TR/html5/interactive-elements.html#selector-required see HTML5 description of being required / required attribute]<br />
*** :read-only and :read-write - [http://www.w3.org/TR/html5/interactive-elements.html#selector-read-only see HTML5 description of read-only vs read-write elements].<br />
** additional pseudo-selectors as needed for states/portions included in HTML5 forms elements features<br />
*** "placeholder" attribute - needs a new :-moz-placeholder pseudo-class ([https://bugzilla.mozilla.org/show_bug.cgi?id=457801 bug 457801])<br />
**** :placeholder pseudo-class needs to be proposed for CSS3.1 UI/Selectors.<br />
* typography<br />
** font properties<br />
** text properties<br />
** color<br />
* box properties<br />
** width<br />
** height<br />
** padding<br />
** border<br />
** margin<br />
** background<br />
** box-shadow<br />
<br />
<br />
3. If there's a constraint API the API must be complete.<br />
<br />
4. It should be [[Accessibility/HTML5_Forms|fully accessible]].<br />
<br />
==== CSS3 UI ====<br />
;latest published draft<br />
:http://www.w3.org/TR/css3-ui/<br />
;latest development / in progress draft<br />
:currently: http://www.w3.org/Style/Group/css3-src/css3-ui/Overview.html<br />
:eventually: <nowiki>http://dev.w3.org/csswg/css3-ui/</nowiki><br />
;spec source (for editing)<br />
:currently: http://www.w3.org/Style/Group/css3-src/css3-ui/Overview.src.html<br />
:eventually: <nowiki>http://dev.w3.org/csswg/css3-ui/Overview.src.html</nowiki><br />
;test suite<br />
:TBD<br />
;implementation reports of the test suite<br />
:TBD<br />
;issues list for the current draft<br />
:http://wiki.csswg.org/spec/css3-ui<br />
<br />
===== remaining tasks =====<br />
Remaining tasks to get CSS3 UI to PR:<br />
<br />
* draft and publish at least a minimal coverage test suite <br />
** and documentation of existing implementations (from public emails on public-html, www-style, etc.)<br />
* reducing feature set down to what's been implemented in more than one browser<br />
** produce a new CSS3 UI LCWD with only non-at-risk features based on above implementation evidence (or imminent implementation)<br />
** while figuring out what we (CSS WG) would want to move / keep for a CSS3.1/4 UI module - perhaps start that draft.<br />
* collect/address new CSS3 UI LCWD issues as they are reported<br />
** respond to all the commenters on issues with proposed resolutions (hopefully thus addressing their concerns and resolving the issues accordingly)<br />
** incrementally draft new CSS3-UI CR draft accordingly<br />
* wait for new CSS3 UI LCWD last-call period to end<br />
* edit CSS3-UI CR draft accordingly that is ready for PR<br />
* WG processes for taking it to PR<br />
<br />
Remaining development tasks (stub/incomplete)<br />
For each of these, figure out who is the right Mozilla developer to work on this and then work with to understand what it will take to get it implemented:<br />
* icon support: http://www.w3.org/TR/css3-ui/#element<br />
** 'icon' property<br />
** 'content:icon' value<br />
* ...<br />
<br />
==== CSS3 Color ====<br />
;latest published draft<br />
:http://www.w3.org/TR/css3-color/<br />
;latest development / in progress draft<br />
:http://dev.w3.org/csswg/css3-color/<br />
;spec source (for editing)<br />
:http://dev.w3.org/csswg/css3-color/Overview.src.html<br />
;test suite<br />
:http://www.w3.org/Style/CSS/Test/CSS3/Color/20080721/<br />
;implementation reports of the test suite<br />
:http://www.w3.org/Style/CSS/Test/CSS3/Color/current/reports/<br />
;issues list for the current last call<br />
:http://wiki.csswg.org/spec/css3-color - once these issues are addressed, it should be ready to go to PR.<br />
<br />
===== remaining tasks =====<br />
Remaining tasks to get CSS3 Color to PR:<br />
* resolve any remaining open issues in the issues list<br />
* respond to all the commenters in the issues list with proposed resolutions (hopefully thus addressing their concerns and resolving the issues accordingly)<br />
** update the disposition of comments accordingly with responses<br />
* do the remaining editing on the draft<br />
** one of them has an action on Chris Lilley to write text<br />
** ...<br />
* reconfirm that any/all dependent specs are in CR (or later)<br />
* Figure out what to do with hixie's tests http://test.csswg.org/source/contributors/hixie/incoming/css3-color/<br />
* collect new features for CSS3.1/4 Color<br />
** follow-up on color management properties for css3-color that were discussed at 2009 November TPAC CSS f2f (but later punted from css3-color to a future version).<br />
*** check minutes from that meeting for details on conclusions of the property (name, values etc.)<br />
*** contact Beth regarding level of implementation interest, plan to move forward with putting the color management property into a post-css3 working draft of the Color Module<br />
* write a first working draft of CSS3.1/4 Color with collected feature(s) (even if it includes just a new color management property)<br />
<br />
=== UI Layout ===<br />
* CSS3 Flex Box<br />
** need to get in touch with Tab Atkins and catch-up on the current state of his work vs. existing prefixed partial implementation in Firefox and Safari.<br />
*** 2010-155 briefly spoke with Tab about flex box in irc and noted that I'm working on css3-color and css3-ui first.<br />
<br />
=== DOM API vendor prefixing ===<br />
==== spec implementation problem statement ====<br />
Problem statement: the '''specification-implementation co-dependency problem'''.<br />
<br />
All standards in development have the challenging seemingly contradictory problems of:<br />
# '''needing some implementation to reality-check''' that the API/protocol/format "works" as intended, or is workable/usable<br />
# '''being stuck with a specific (often buggy) implementation''' once it ships because there's content/pages/apps out there that depend on it.<br />
<br />
There are three areas of the open web app platform that this has been problematic:<br />
# '''CSS'''. In the past, some properties were implemented, either as spec'd (and the spec was buggy), or in a way that made sense but incompatible with the spec (because the spec didn't make sense or was not useful to web authors), and then we got "stuck" with those implementations and were not able to update/fix the spec and the respective properties and/or values. Examples:<br />
## 'clip' property. mis-specified in CSS 2.0. implemented as presumed intended in IE4/Windows etc. but turned out to be buggy. some content started depending on it. we (CSS WG at the time) were unable to really fix it in a way that implementations could change, though [http://www.w3.org/TR/CSS21/visufx.html#clipping CSS 2.1 tries to fix clip].<br />
## 'word-wrap' property. in this case, created/proposed by Microsoft, and [http://msdn.microsoft.com/en-us/library/ms531186.aspx implemented as of IE5.5/Windows ca 2000], we are again, kind of stuck with the particular implementation. [http://www.codingforums.com/archive/index.php/t-2075.html Forum posts as of 2002 were recommending use of the literal word-wrap property]. Though since Microsoft did switch to advocating/supporting a prefixed version '-ms-word-wrap'. Note that it is also [https://developer.mozilla.org/en/CSS/word-wrap supported in Firefox 3.5 ca 2009], and it is in the latest (2007) version of the [http://www.w3.org/TR/2007/WD-css3-text-20070306/#word-wrap CSS3 Text spec which is just a working draft].<br />
### See related 'word-break' property ([http://www.w3.org/TR/2007/WD-css3-text-20070306/#word-break word-break in CSS3 Text WD] - latest, 2007), also [http://msdn.microsoft.com/en-us/library/ms531184.aspx initially (partially) implemented in Internet Explorer 5.x as word-break], and later switched to the prefixed '-ms-word-break'. [http://msdn.microsoft.com/en-us/library/cc351024%28VS.85%29.aspx More on CSS Compatibility and Internet Explorer].<br />
# '''HTML'''. Too many examples to list here. Some browsers are still stuck supporting <code>&lt;blink&gt;</code> and <code>&lt;marquee&gt;</code> (which has many odd details), nevermind the classic example of <code>&lt;table&gt;</code> layout, with tons of odd special cases and error-handling for compat, originally from Netscape's implementation, reverse-engineered by Microsoft in Internet Explorer, which has subsequently been reverse-engineered by every other browser.<br />
# '''DOM'''. In particular [http://www.w3.org/TR/2009/WD-webstorage-20091222/ Web Storage working draft] (e.g. the 'localStorage' attribute/property) was implemented in multiple browsers (IE8+, Chrome, Safari, Opera, Mozilla as of 2010 - date order unknown). By the time people discovered it was not threadsafe as specified, it was too late to change the spec to fix that problem - it would have broken too many apps/sites already written which apparently depended on it.<br />
<br />
==== existing solutions ====<br />
<br />
The only one of these areas of technology that has an explicit solution to the specification-implementation co-dependency problem is CSS, through vendor-prefixes.<br />
<br />
===== CSS vendor prefixes =====<br />
In the early 2000s the participants in the CSS working group agreed to formalize a way for implementors to build experimental implementations of new properties and values which were only in a working draft (not yet in a Candidate Recommendation) without saddling the property with implementation specific bugs that content would end up inadvertently depending on.<br />
<br />
CSS prefixing is fairly straight forward:<br />
<br />
<pre>- abbreviated_vendor_prefix - property_name</pre><br />
<br />
(spaces added for clarification of the different components)<br />
<br />
Examples include:<br />
* -moz-opacity<br />
* -o-border-radius<br />
* -webkit-border-radius<br />
* -ms-word-wrap<br />
<br />
===== CSS vendor prefixes case studies =====<br />
* '''border-radius'''. for a few years now browsers have been implementing ''vendor prefixed'' versions of the border-radius properties, web authors have been experimenting on the web, and the spec has iterated/improved based on feedback. Now we have a well-designed and road-tested 'border-radius' property in a CR spec and implementations are implementing that.<br />
* '''word-wrap vs whitespace: pre-wrap'''. interactions between new properties and new values on existing properties. See this [http://scottonwriting.net/sowBlog/archive/0000/00/00/163005.aspx example of the property vs value interaction] between the new 'word-wrap' property and the (sometimes prefixed) new 'pre-wrap' value on the 'whitespace' property. The point is to show how prefixing can actually work across different approaches to evolving CSS.<br />
<br />
==== analysis of applicability ====<br />
Can we apply similar thinking and solutions to HTML and/or DOM?<br />
<br />
For HTML (or any markup) the thinking is no - because of the fact that an element only allows one tagname, there is no way to have content first use a vendor prefixed tagname (or tagnames from multiple vendors), and then also use a final unprefixed tagname all at the same time as part of a content evolution/transition strategy. CSS vendor prefixing works (as illustrated in the case studies) because authors ''can'' create style sheets that use multiple versions of a property (vendor prefixed and unprefixed) in one style sheet, together while evolving their content over time.<br />
<br />
For DOM, it is not only possible, but there are examples in the wild.<br />
<br />
[https://developer.mozilla.org/en/DOM/window.onmozorientation mozOrientation] is a good example of a vendor prefixed DOM interface implementation. (Note mozOrientation needs to be submitted to a W3C working group for standardization/iteration)<br />
<br />
==== simple DOM vendor prefixes proposal ====<br />
<br />
For all DOM interfaces that are:<br />
* Proprietary. No standards organization draft yet published. OR<br />
* In a W3C working draft, not yet in a Candidate Recommendation.<br />
<br />
Use vendor prefixed interfaces and values as follows:<br />
<br />
<pre>vendor_prefix _ unprefixed_name</pre><br />
<br />
E.g. in the above example of mozOrientation, we really should be using:<br />
<br />
<pre>moz_Orientation</pre><br />
<br />
This works because standard DOM APIs do not use underscores.<br />
<br />
Our goal is to establish a convention (like the above) for all such pre-CR DOM APIs that has the consensus of implementers so that we can avoid creating broken versions of APIs<br />
<br />
== Social and Identity ==<br />
=== Related Features ===<br />
Features to work with:<br />
* Accounts Manager<br />
* ...<br />
=== Standards and Communities ===<br />
Standards and communities to engage with (recommended, unprioritized)<br />
* vCard 4 (IETF vcarddav)<br />
* hCard (microformats.org)<br />
* microdata vcard vocab (W3C/WhatWG)<br />
* OAuth (including OAuth 2, xAuth, OWF)<br />
* Portable Contacts<br />
* RelMeAuth<br />
* OpenID<br />
* WebFinger<br />
* Activity Streams<br />
* ...<br />
<br />
== Events ==<br />
Events I'm planning on participating in accordingly:<br />
* June 28-30 Voices That Matter Web Design in SF http://www.voicesthatmatter.com/webdesign2010<br />
* July 5-7 Mozilla Summit in Whistler, Canada.<br />
* July 19-23 OSCON in Portland http://www.oscon.com/oscon2010<br />
* August 23-25 W3C CSS WG f2f in Oslo http://www.w3.org/Style/Group/2010/Oslo<br />
* September 3 dConstruct in Brighton http://2010.dConstruct.org/<br />
<br />
== Reference ==<br />
=== Pages ===<br />
Reference pages created:<br />
* [[CSS3]]<br />
** [[CSS3/color|color module]]<br />
** [[CSS3/ui|ui module]]<br />
* [[HTML5]]<br />
** [[HTML5/canvas|&lt;canvas&gt;]]<br />
** [[HTML5/input|&lt;input&gt;]]<br />
<br />
=== Done ===<br />
Completed tasks, projects, events that have no further related active work items. Will likely move to its own page as it grows, in which case, I'll probably just keep *recently* finished items here and regularly archive them.<br />
<br />
* June 1-3 Open Source Bridge, Portland, OR, http://opensourcebridge.org</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Websites/Mozilla.org/Archive/About&diff=213498Websites/Mozilla.org/Archive/About2010-04-05T23:29:29Z<p>Fantasai: /* New Governance Text */ scribbles</p>
<hr />
<div>This wiki page is a place to collect ideas for updates to the [http://www.mozilla.org/about About Mozilla] page on www.mozilla.org.<br />
<br />
=Plan=<br />
<br />
Our current thinking is that the current About and Causes section should be merged since talking About Mozilla and Mozilla's mission separately just doesn't make much sense. The following is a plan for combining this content.<br />
<br />
==Causes Section==<br />
<br />
All content in the Causes section now should be moved or deleted.<br />
<br />
===To Move===<br />
<br />
* http://www.mozilla.org/causes/index.html<br />
* http://www.mozilla.org/causes/better.html<br />
<br />
These pages are the key part of the mission message and should be moved to a new Mission page in the About section.<br />
<br />
* http://www.mozilla.org/causes/grants/<br />
<br />
This content has already been moved to a top-level Grants section.<br />
<br />
===To Delete and Redirect===<br />
<br />
* http://www.mozilla.org/causes/access.html<br />
* http://www.mozilla.org/causes/education.html<br />
* http://www.mozilla.org/causes/free.html<br />
* http://www.mozilla.org/causes/security.html<br />
* http://www.mozilla.org/causes/openweb.html<br />
<br />
There may be relevant content from these pages that are worth keeping, but the pages themselves don't need to be migrated.<br />
<br />
===Not Sure===<br />
<br />
* http://www.mozilla.org/causes/serviceweek<br />
* http://www.mozilla.org/causes/onewebday<br />
* http://www.mozilla.org/causes/open<br />
<br />
We haven't decided if completed campaign pages should still be available or if they should be removed. Probably needs to be decided on case by case basis. Anything that should remain can be moved to a more appropriate place. <br />
<br />
For future campaigns we can create a central repository for them or add them where appropriate. For instance, the Parks pages live in www.mozilla.org/parks instead of a specific campaign location.<br />
<br />
==About Section==<br />
<br />
The main issue in the About section is that the Manifesto is not the best way to introduce people to our community's mission and values. The Manifesto is the foundation for the mission, but we need a new Mission page that can then link to the Manifesto for anyone wanting to learn more. The main About page will also need to be rewritten to focus more on the mission and less on the community structure (which is important but can live on it's own page in the section).<br />
<br />
===New About Text===<br />
<br />
<br />
===New Mission Text===<br />
<br />
Mission<br />
<br />
Mozilla's mission is to promote an open, shared and innovative Internet. [http://www.firefox.com Firefox], [http://www.drumbeat.org Drumbeat] and our other [http://www.mozilla.org/projects projects] are the tools our community uses to build a better Web.<br />
<br />
* An open Internet allows people to make new and unanticipated things online.<br />
* A shared Internet enables people to work together to reach common goals.<br />
* An innovative Internet gives people the opportunity to build onto the Web as it is today.<br />
<br />
The [http://www.mozilla.org/foundation Mozilla Foundation] is a non-profit organization dedicated to these goals, but the real force behind Mozilla is people around the world taking action to build the Web they want. [http://www.mozilla.org/contribute And you can help]!<br />
<br />
Promo: Learn more about the [http://www.mozilla.org/about/manifesto values and principles] that guide the pursuit of our mission.<br />
<br />
''Note: Potential design/copy direction can be seen in [http://designaction.org/clients/mozilla/causes_page/r1.htm initial mockups for new Causes main page].''<br />
<br />
<br />
''Note: fantasai thinks we should go with openness, innovation, and opportunity wording for now, since it's the most official, being both in the officially-approved Manifesto and on Mitchell's blog (Mitchell being the most offical person). And then argue that sharing is a means to that end.''<br />
<br />
===New Governance Text===<br />
<br />
Governance<br />
<br />
Mozilla is governed by a virtual management team made up of unpaid experts and employees from a range of companies. As an [http://www.opensource.org/ open source] project structured as a [http://en.wikipedia.org/wiki/Meritocracy meritocracy], responsibility is distributed to any community member as they show their abilities through contributions to the project. <br />
<br />
''Mozilla is an [http://www.opensource.org/ open source] project governed as a [http://en.wikipedia.org/wiki/Meritocracy meritocracy]. Our community is structured as a virtual organization where authority is distributed to both volunteer and employed community members as they show their abilities through contributions to the project.''<br />
<br />
''fantasai's doodles: Authority is what's distributed meritocratically. Responsibility is pretty much up for grabs: fulfilling responsibilities you take on is how you earn authority.''<br />
<br />
Learn more about who is involved with governance and how our global community works together on our common _mission_.<br />
<br />
'''Roles and Responsibilities'''<br />
http://www.mozilla.org/about/roles.html<br />
<br />
'''Policies'''<br />
http://www.mozilla.org/about/policies/<br />
<br />
'''Discussions'''<br />
http://groups.google.com/group/mozilla.governance/topics<br />
<br />
===New Navigation===<br />
<br />
* Mission (or Mozilla's Mission?)<br />
* Governance<br />
* Organizations<br />
* Grants<br />
* History<br />
* FAQs<br />
<br />
''Note: Remember to update links in footer when updating the nav in this section.''<br />
<br />
==Coding Thoughts==<br />
<br />
Our goal for www.mozilla.org pages is to help advance web standards where possible. This page is light on design elements so there's not much opportunity to use some standards such as canvas or SVG. Our thinking is that this could be a good opportunity to showcase the new WOFF format. Some relevant links:<br />
<br />
* [http://hacks.mozilla.org/2009/10/woff/ Web Open Font Format for Firefox 3.6]<br />
* [http://fontfeed.com/archives/fontfonts-on-the-web-starting-today/ FontFonts on the Web, Starting Today]<br />
* [http://www.edenspiekermann.com/woff/ Page about Meta font and WOFF]<br />
<br />
''Note: We have a license for WOFF and EOT versions of the Meta fonts.''<br />
<br />
==Duplicated Pages==<br />
<br />
* http://www.mozilla.com/about/whatismozilla.html</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Websites/Mozilla.org/Archive/About&diff=213493Websites/Mozilla.org/Archive/About2010-04-05T23:00:45Z<p>Fantasai: /* New Mission Text */</p>
<hr />
<div>This wiki page is a place to collect ideas for updates to the [http://www.mozilla.org/about About Mozilla] page on www.mozilla.org.<br />
<br />
=Plan=<br />
<br />
Our current thinking is that the current About and Causes section should be merged since talking About Mozilla and Mozilla's mission separately just doesn't make much sense. The following is a plan for combining this content.<br />
<br />
==Causes Section==<br />
<br />
All content in the Causes section now should be moved or deleted.<br />
<br />
===To Move===<br />
<br />
* http://www.mozilla.org/causes/index.html<br />
* http://www.mozilla.org/causes/better.html<br />
<br />
These pages are the key part of the mission message and should be moved to a new Mission page in the About section.<br />
<br />
* http://www.mozilla.org/causes/grants/<br />
<br />
This content has already been moved to a top-level Grants section.<br />
<br />
===To Delete and Redirect===<br />
<br />
* http://www.mozilla.org/causes/access.html<br />
* http://www.mozilla.org/causes/education.html<br />
* http://www.mozilla.org/causes/free.html<br />
* http://www.mozilla.org/causes/security.html<br />
* http://www.mozilla.org/causes/openweb.html<br />
<br />
There may be relevant content from these pages that are worth keeping, but the pages themselves don't need to be migrated.<br />
<br />
===Not Sure===<br />
<br />
* http://www.mozilla.org/causes/serviceweek<br />
* http://www.mozilla.org/causes/onewebday<br />
* http://www.mozilla.org/causes/open<br />
<br />
We haven't decided if completed campaign pages should still be available or if they should be removed. Probably needs to be decided on case by case basis. Anything that should remain can be moved to a more appropriate place. <br />
<br />
For future campaigns we can create a central repository for them or add them where appropriate. For instance, the Parks pages live in www.mozilla.org/parks instead of a specific campaign location.<br />
<br />
==About Section==<br />
<br />
The main issue in the About section is that the Manifesto is not the best way to introduce people to our community's mission and values. The Manifesto is the foundation for the mission, but we need a new Mission page that can then link to the Manifesto for anyone wanting to learn more. The main About page will also need to be rewritten to focus more on the mission and less on the community structure (which is important but can live on it's own page in the section).<br />
<br />
===New About Text===<br />
<br />
<br />
===New Mission Text===<br />
<br />
Mission<br />
<br />
Mozilla's mission is to promote an open, shared and innovative Internet. [http://www.firefox.com Firefox], [http://www.drumbeat.org Drumbeat] and our other [http://www.mozilla.org/projects projects] are the tools our community uses to build a better Web.<br />
<br />
* An open Internet allows people to make new and unanticipated things online.<br />
* A shared Internet enables people to work together to reach common goals.<br />
* An innovative Internet gives people the opportunity to build onto the Web as it is today.<br />
<br />
The [http://www.mozilla.org/foundation Mozilla Foundation] is a non-profit organization dedicated to these goals, but the real force behind Mozilla is people around the world taking action to build the Web they want. [http://www.mozilla.org/contribute And you can help]!<br />
<br />
Promo: Learn more about the [http://www.mozilla.org/about/manifesto values and principles] that guide the pursuit of our mission.<br />
<br />
''Note: Potential design/copy direction can be seen in [http://designaction.org/clients/mozilla/causes_page/r1.htm initial mockups for new Causes main page].''<br />
<br />
<br />
''Note: fantasai thinks we should go with openness, innovation, and opportunity wording for now, since it's the most official, being both in the officially-approved Manifesto and on Mitchell's blog (Mitchell being the most offical person). And then argue that sharing is a means to that end.''<br />
<br />
===New Governance Text===<br />
<br />
Governance<br />
<br />
Mozilla is governed by a virtual management team made up of unpaid experts and employees from a range of companies. As an [http://www.opensource.org/ open source] project structured as a [http://en.wikipedia.org/wiki/Meritocracy meritocracy], responsibility is distributed to any community member as they show their abilities through contributions to the project. <br />
<br />
Learn more about who is involved with governance and how a global community works together on a common mission.<br />
<br />
'''Roles and Responsibilities'''<br />
http://www.mozilla.org/about/roles.html<br />
<br />
'''Policies'''<br />
http://www.mozilla.org/about/policies/<br />
<br />
'''Discussions'''<br />
http://groups.google.com/group/mozilla.governance/topics<br />
<br />
===New Navigation===<br />
<br />
* Mission (or Mozilla's Mission?)<br />
* Governance<br />
* Organizations<br />
* Grants<br />
* History<br />
* FAQs<br />
<br />
''Note: Remember to update links in footer when updating the nav in this section.''<br />
<br />
==Coding Thoughts==<br />
<br />
Our goal for www.mozilla.org pages is to help advance web standards where possible. This page is light on design elements so there's not much opportunity to use some standards such as canvas or SVG. Our thinking is that this could be a good opportunity to showcase the new WOFF format. Some relevant links:<br />
<br />
* [http://hacks.mozilla.org/2009/10/woff/ Web Open Font Format for Firefox 3.6]<br />
* [http://fontfeed.com/archives/fontfonts-on-the-web-starting-today/ FontFonts on the Web, Starting Today]<br />
* [http://www.edenspiekermann.com/woff/ Page about Meta font and WOFF]<br />
<br />
''Note: We have a license for WOFF and EOT versions of the Meta fonts.''<br />
<br />
==Duplicated Pages==<br />
<br />
* http://www.mozilla.com/about/whatismozilla.html</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Websites/Mozilla.org/Archive/About&diff=213492Websites/Mozilla.org/Archive/About2010-04-05T22:59:58Z<p>Fantasai: /* New Mission Text */</p>
<hr />
<div>This wiki page is a place to collect ideas for updates to the [http://www.mozilla.org/about About Mozilla] page on www.mozilla.org.<br />
<br />
=Plan=<br />
<br />
Our current thinking is that the current About and Causes section should be merged since talking About Mozilla and Mozilla's mission separately just doesn't make much sense. The following is a plan for combining this content.<br />
<br />
==Causes Section==<br />
<br />
All content in the Causes section now should be moved or deleted.<br />
<br />
===To Move===<br />
<br />
* http://www.mozilla.org/causes/index.html<br />
* http://www.mozilla.org/causes/better.html<br />
<br />
These pages are the key part of the mission message and should be moved to a new Mission page in the About section.<br />
<br />
* http://www.mozilla.org/causes/grants/<br />
<br />
This content has already been moved to a top-level Grants section.<br />
<br />
===To Delete and Redirect===<br />
<br />
* http://www.mozilla.org/causes/access.html<br />
* http://www.mozilla.org/causes/education.html<br />
* http://www.mozilla.org/causes/free.html<br />
* http://www.mozilla.org/causes/security.html<br />
* http://www.mozilla.org/causes/openweb.html<br />
<br />
There may be relevant content from these pages that are worth keeping, but the pages themselves don't need to be migrated.<br />
<br />
===Not Sure===<br />
<br />
* http://www.mozilla.org/causes/serviceweek<br />
* http://www.mozilla.org/causes/onewebday<br />
* http://www.mozilla.org/causes/open<br />
<br />
We haven't decided if completed campaign pages should still be available or if they should be removed. Probably needs to be decided on case by case basis. Anything that should remain can be moved to a more appropriate place. <br />
<br />
For future campaigns we can create a central repository for them or add them where appropriate. For instance, the Parks pages live in www.mozilla.org/parks instead of a specific campaign location.<br />
<br />
==About Section==<br />
<br />
The main issue in the About section is that the Manifesto is not the best way to introduce people to our community's mission and values. The Manifesto is the foundation for the mission, but we need a new Mission page that can then link to the Manifesto for anyone wanting to learn more. The main About page will also need to be rewritten to focus more on the mission and less on the community structure (which is important but can live on it's own page in the section).<br />
<br />
===New About Text===<br />
<br />
<br />
===New Mission Text===<br />
<br />
Mission<br />
<br />
Mozilla's mission is to promote an open, shared and innovative Internet. [http://www.firefox.com Firefox], [http://www.drumbeat.org Drumbeat] and our other [http://www.mozilla.org/projects projects] are the tools our community uses to build a better Web.<br />
<br />
* An open Internet allows people to make new and unanticipated things online.<br />
* A shared Internet enables people to work together to reach common goals.<br />
* An innovative Internet gives people the opportunity to build onto the Web as it is today.<br />
<br />
The [http://www.mozilla.org/foundation Mozilla Foundation] is a non-profit organization dedicated to these goals, but the real force behind Mozilla is people around the world taking action to build the Web they want. [http://www.mozilla.org/contribute And you can help]!<br />
<br />
Promo: Learn more about the [http://www.mozilla.org/about/manifesto values and principles] that guide the pursuit of our mission.<br />
<br />
''Note: Potential design/copy direction can be seen in [http://designaction.org/clients/mozilla/causes_page/r1.htm initial mockups for new Causes main page].''<br />
<br />
<br />
''Note: fantasai thinks we should go with openness, innovation, and opportunity wording for now, since it's the most official, being both in the officially-approved Manifesto and on Mitchell's blog (Mitchell being the most offical person).''<br />
<br />
===New Governance Text===<br />
<br />
Governance<br />
<br />
Mozilla is governed by a virtual management team made up of unpaid experts and employees from a range of companies. As an [http://www.opensource.org/ open source] project structured as a [http://en.wikipedia.org/wiki/Meritocracy meritocracy], responsibility is distributed to any community member as they show their abilities through contributions to the project. <br />
<br />
Learn more about who is involved with governance and how a global community works together on a common mission.<br />
<br />
'''Roles and Responsibilities'''<br />
http://www.mozilla.org/about/roles.html<br />
<br />
'''Policies'''<br />
http://www.mozilla.org/about/policies/<br />
<br />
'''Discussions'''<br />
http://groups.google.com/group/mozilla.governance/topics<br />
<br />
===New Navigation===<br />
<br />
* Mission (or Mozilla's Mission?)<br />
* Governance<br />
* Organizations<br />
* Grants<br />
* History<br />
* FAQs<br />
<br />
''Note: Remember to update links in footer when updating the nav in this section.''<br />
<br />
==Coding Thoughts==<br />
<br />
Our goal for www.mozilla.org pages is to help advance web standards where possible. This page is light on design elements so there's not much opportunity to use some standards such as canvas or SVG. Our thinking is that this could be a good opportunity to showcase the new WOFF format. Some relevant links:<br />
<br />
* [http://hacks.mozilla.org/2009/10/woff/ Web Open Font Format for Firefox 3.6]<br />
* [http://fontfeed.com/archives/fontfonts-on-the-web-starting-today/ FontFonts on the Web, Starting Today]<br />
* [http://www.edenspiekermann.com/woff/ Page about Meta font and WOFF]<br />
<br />
''Note: We have a license for WOFF and EOT versions of the Meta fonts.''<br />
<br />
==Duplicated Pages==<br />
<br />
* http://www.mozilla.com/about/whatismozilla.html</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Websites/Mozilla.org/Archive/About&diff=199861Websites/Mozilla.org/Archive/About2010-02-04T20:04:40Z<p>Fantasai: /* New Text */ revision</p>
<hr />
<div>This wiki page is a place to collect ideas for updates to the [http://www.mozilla.org/about About Mozilla] page on www.mozilla.org.<br />
<br />
==New Text==<br />
<br />
''Note: this is a draft and is subject to change.''<br />
<br />
{page title} About Mozilla<br />
<br />
{font}We’re a global [http://www.mozilla.org/community community]{/font}<br />
<br />
of thousands working together since 1998 to build a better Internet.<br />
<br />
{font}We’re a non-profit organization{/font}<br />
<br />
dedicated to promoting and preserving an [http://www.mozilla.org/causes open, shared and innovative web].<br />
<br />
{font}And we’re an [http://www.opensource.org/docs/osd open source] software project{/font}<br />
<br />
whose [http://www.mozilla.org/projects code] has been used to build some of the Internet’s most innovative applications.<br />
<br />
The common thread that runs throughout Mozilla is our belief that, as the most significant social and technological development of our time, the Internet is a public resource that must remain open and accessible to all. With this in mind, our efforts are ultimately driven by our [http://www.mozilla.org/about/manifesto mission] of encouraging openness and opportunity, innovation and participation online.<br />
<br />
To achieve these goals, we use a highly transparent, collaborative process that brings together dedicated volunteers from around the world with a small staff of employees to coordinate the creation of products like the [http://firefox.com Firefox] web browser. Our volunteers and employees work together with equal respect and authority in a virtual meritocracy, and the technology we build we dedicate to everyone as a free, shared public resource.<br />
<br />
In the end, the Mozilla community, organization and technology are all focused on a single goal: '''making the Internet better for everyone'''. [http://www.mozilla.org/contribute Join us]!<br />
<br />
==Promos==<br />
<br />
We'd like to add a promo(s) to the page to highlight various things, such as donations, ways to contribute to the community, etc. For example of how promos are used on other pages, see the [[Mozilla.org/Promo_spots|Promo documentation]].<br />
<br />
==New Navigation==<br />
<br />
Goal: Reorder nav from alphabetical list to a list based on importance of content and move any unrelated material (specifically the [http://www.mozilla.org/about/brochure Brochure] link which should be moved to a location with other material for events.).<br />
<br />
* Mozilla Manifesto<br />
* Organizations<br />
* Roles and Leadership<br />
* Policies<br />
* History<br />
* FAQs<br />
* Support<br />
<br />
''Note: Remember to update links in footer when updating the nav in this section.''<br />
<br />
==Coding Thoughts==<br />
<br />
Our goal for www.mozilla.org pages is to help advance web standards where possible. This page is light on design elements so there's not much opportunity to use some standards such as canvas or SVG. Our thinking is that this could be a good opportunity to showcase the new WOFF format. Some relevant links:<br />
<br />
* [http://hacks.mozilla.org/2009/10/woff/ Web Open Font Format for Firefox 3.6]<br />
* [http://fontfeed.com/archives/fontfonts-on-the-web-starting-today/ FontFonts on the Web, Starting Today]<br />
* [http://www.edenspiekermann.com/woff/ Page about Meta font and WOFF]<br />
<br />
''Note: We have a license for WOFF and EOT versions of the Meta fonts.''<br />
<br />
==Mockups==<br />
<br />
* [http://designaction.org/clients/mozilla/r1.htm First Round]<br />
* [http://designaction.org/clients/mozilla/r2.htm Second Round]<br />
<br />
==Duplicated Pages==<br />
<br />
* http://www.mozilla.com/about/whatismozilla.html</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Platform&diff=188731Platform2009-12-11T00:01:17Z<p>Fantasai: /* Platform Team Goals */</p>
<hr />
<div>This wiki page is devoted to the planning, scheduling, and documenting of meetings, discussions, and status of the Mozilla platform teams.<br />
<br />
=== Current Release ===<br />
Gecko 1.9.1 has been released with [[Firefox 3.5]] and as XULRunner 1.9.1. Gecko 1.9.2 is currently under development for release with "[[Firefox 3.6]] ([[Firefox/Namoroka|Namoroka]]").<br />
<br />
[[Firefox/3.6 | Interesting Firefox 3.6 / Gecko 1.9.2 Bugzilla Queries]]<br />
[http://people.mozilla.com/~mnandigama/dashboard.html Bug and code coverage dashboard]<br />
<br />
=== Planning ===<br />
* See [[Platform/Planning | The Platform Planning Page]] for notes on upcoming releases and planning events. (NOTE: this used to be the [[Platform/Post1.9Planning | Post1.9Planning Spreadsheets for all releases after 1.9.]]).<br />
* See also [[Firefox/Namoroka#Firefox.next Platform Requirements]] and its talk page.<br />
* See also the [[Platform/Wanted|Wanted]] page for a few items wanted by extension/application developers<br />
<br />
=== Platform Team Goals ===<br />
* [[Platform/2010-Q1-Goals | 2010 Q1 Goals]]<br />
* [[Platform/2009-Q4-Goals | 2009 Q4 Goals]]<br />
* [[Platform/2009-Q3-Goals | 2009 Q3 Goals]]<br />
* [[Platform/2009-Q2-Goals | 2009 Q2 Goals]]<br />
* [[Platform/2009-Q1-Goals | 2009 Q1 Goals]]<br />
* [[Platform/2008-Q4-Goals | 2008 Q4 Goals]]<br />
* [[Platform/2008-Q3-Goals | 2008 Q3 Goals]]<br />
* [[Platform/2008-Q2-Goals | 2008 Q2 Goals]]<br />
* [[Platform/2008-Q1-Goals | 2008 Q1 Goals]]<br />
* [[Platform/2007-Q3-Goals | 2007 Q3 Goals]]<br />
* [[Platform/2007-Q2-Goals | 2007 Q2 Goals]]<br />
<br />
=== Meetings ===<br />
A weekly meeting is held to discuss the current release of Gecko. <br />
Meeting Details:<br />
* Tuesdays - 11:00am Pacific, 2:00pm Eastern, 18:00 UTC<br />
* Mozilla Building, Mozilla Square Conference Room<br />
* 650-903-0800 or 650-215-1282 x92 Conf# 8605 (US/INTL)<br />
* 1-800-707-2533 (pin 369) Conf# 8605 (US)<br />
* [irc://irc.mozilla.org/planning irc.mozilla.org #planning] for backchannel<br />
<br />
Watch the mozilla.dev.planning forum ([https://lists.mozilla.org/listinfo/dev-planning mailing list] | [http://groups.google.com/group/mozilla.dev.planning mozilla.dev.planning Google Group]) for weekly agendas and dial in details.<br />
<br />
Look [[Mozilla_2/StatusMeetings | here]] for previous meeting notes while under the guise of Mozilla 2.<br />
<br />
== Meeting Notes ([[Platform/0-0-0|template]]) ==<br />
* [[Platform/2009-12-01|01-Dec-2009]]<br />
* [[Platform/2009-11-24|24-Nov-2009]]<br />
* [[Platform/2009-11-17|17-Nov-2009]]<br />
* [[Platform/2009-11-10|10-Nov-2009]]<br />
* [[Platform/2009-11-03|03-Nov-2009]]<br />
* [[Platform/2009-10-27|27-Oct-2009]]<br />
* [[Platform/2009-10-20|20-Oct-2009]]<br />
* [[Platform/2009-10-13|13-Oct-2009]]<br />
* [[Platform/2009-10-06|06-Oct-2009]]<br />
* [[Platform/2009-09-29|29-Sep-2009]]<br />
* [[Platform/2009-09-22|22-Sep-2009]]<br />
* [[Platform/2009-09-15|15-Sep-2009]]<br />
* [[Platform/2009-09-08|08-Sep-2009]]<br />
* [[Platform/2009-09-01|01-Sep-2009]]<br />
* [[Platform/2009-08-25|25-Aug-2009]]<br />
* [[Platform/2009-08-18|18-Aug-2009]]<br />
* [[Platform/2009-08-11|11-Aug-2009]]<br />
* [[Platform/2009-08-04|04-Aug-2009]]<br />
* [[Platform/2009-07-28|28-Jul-2009]]<br />
* [[Platform/2009-07-21|21-Jul-2009]]<br />
* [[Platform/2009-07-14|14-Jul-2009]]<br />
* [[Platform/2009-07-07|07-Jul-2009]]<br />
* [[Platform/2009-06-30|30-Jun-2009]]<br />
* [[Platform/2009-06-23|23-Jun-2009]]<br />
* [[Platform/2009-06-16|16-Jun-2009]]<br />
* [[Platform/2009-06-09|09-Jun-2009]]<br />
* [[Platform/2009-06-02|02-Jun-2009]]<br />
* [[Platform/2009-05-26|26-May-2009]]<br />
* [[Platform/2009-05-19|19-May-2009]]<br />
* [[Platform/2009-05-12|12-May-2009]]<br />
* [[Platform/2009-05-05|05-May-2009]]<br />
* [[Platform/2009-04-21|21-Apr-2009]]<br />
* [[Platform/2009-04-14|14-Apr-2009]]<br />
* [[Platform/2009-04-07|07-Apr-2009]]<br />
* [[Platform/2009-03-31|31-Mar-2009]]<br />
* [[Platform/2009-03-24|24-Mar-2009]]<br />
* [[Platform/2009-03-17|17-Mar-2009]]<br />
* [[Platform/2009-03-10|10-Mar-2009]]<br />
* [[Platform/2009-03-03|03-Mar-2009]]<br />
* [[Platform/2009-02-24|24-Feb-2009]]<br />
* [[Platform/2009-02-17|17-Feb-2009]]<br />
* [[Platform/2009-02-10|10-Feb-2009]]<br />
* [[Platform/2009-02-03|03-Feb-2009]]<br />
* [[Platform/2009-01-27|27-Jan-2009]]<br />
* [[Platform/2009-01-20|20-Jan-2009]]<br />
* [[Platform/2009-01-13|13-Jan-2009]]<br />
* [[Platform/2009-01-06|06-Jan-2009]]<br />
* 30-Dec-2008 - canceled<br />
* [[Platform/2008-12-23|23-Dec-2008]]<br />
* [[Platform/2008-12-16|16-Dec-2008]]<br />
* [[Platform/2008-12-09|09-Dec-2008]]<br />
* [[Platform/2008-12-02|02-Dec-2008]]<br />
* [[Platform/2008-11-25|25-November-2008]]<br />
* [[Platform/2008-11-18|18-November-2008]]<br />
* [[Platform/2008-11-11|11-November-2008]]<br />
* [[Platform/2008-11-04|04-November-2008]]<br />
* [[Platform/2008-10-28|28-October-2008]]<br />
* [[Platform/2008-10-21|21-October-2008]]<br />
* [[Platform/2008-10-14|14-October-2008]]<br />
* [[Platform/2008-10-07|7-October-2008]]<br />
* [[Platform/2008-09-30|30-September-2008]]<br />
* [[Platform/2008-09-23|23-September-2008]]<br />
* [[Platform/2008-09-16|16-September-2008]]<br />
* [[Platform/2008-09-09|09-September-2008]]<br />
* [[Platform/2008-09-02|02-September-2008]]<br />
* [[Platform/2008-08-27|27-August-2008]]<br />
* [[Platform/2008-08-20|20-August-2008]]<br />
* [[Platform/2008-08-13|13-August-2008]]<br />
* [[Platform/2008-08-06|06-August-2008]]<br />
* [[Platform/2008-07-23|23-July-2008]]<br />
* [[Platform/2008-07-16|16-July-2008]]<br />
* [[Platform/2008-07-09|09-July-2008]]<br />
* [[Platform/2008-07-02|02-July-2008]]<br />
<br />
=== Mozilla Platform Functional Groups ===<br />
Some teams have their own meetings during the week to discuss specific issues:<br />
* [[Platform/Layout | Layout Team]]<br />
* [[Platform/GFX | Graphics Team]]<br />
* [[Platform/Mac | Mac Team]]<br />
* [[Platform/Content | Content Team]]<br />
* [[Platform/JS | JavaScript Team]]<br />
* [[Mozilla 2]]</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Platform/2010-Q1-Goals&diff=188727Platform/2010-Q1-Goals2009-12-10T23:42:13Z<p>Fantasai: /* Layout */</p>
<hr />
<div>=== Layout ===<br />
<br />
* Improve the Web platform by contributing to tests and specifications<br />
** Publish CSS2.1 test suite RC [fantasai]<br />
** evaluating layout specs [dbaron]<br />
* Improve the Web platform by implementing key features and correctness fixes<br />
** finish attribute support [dholbert, jwatt]<br />
** <animateMotion> [dholbert]<br />
** fix SVG text bugs [jwatt]<br />
** tabindex in SVG [jwatt]<br />
** Unicode 5.2 [smontagu]<br />
** Sync JS and Gecko Unicode [smontagu]<br />
** missing css3-background [zwol]<br />
** calc() [dbaron]<br />
** finish up transitions [dbaron]<br />
** author control over color management? [dbaron]<br />
** SVG in images [?]<br />
** nothing selector matching [?]<br />
* Improve perceived and measured performance<br />
** opacity optimization [jwatt]<br />
** incremental bidi resolver [jfkthame]<br />
** CSS parsing performance [zwol]<br />
** lazy frame construction [tnikkel]<br />
** harfbuzz [jfkthame]<br />
** splitting overflow areas and updating overflow areas without reflow [karl]<br />
** de-BRification [ehsan]<br />
* General product improvement<br />
** view hierarchy integration [roc]<br />
** zooming within display list [tnikkel]<br />
** layers (basic + retained) [roc]<br />
** plugin owned by content [?]<br />
<br />
Other ideas: text-overflow, ruby, compositor phase II</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Platform/2010-Q1-Goals&diff=188726Platform/2010-Q1-Goals2009-12-10T23:35:50Z<p>Fantasai: /* Layout */</p>
<hr />
<div>=== Layout ===<br />
<br />
* Improve the Web platform by contributing to tests and specifications<br />
** Publish CSS2.1 test suite RC [fantasai]<br />
** evaluating layout specs [dbaron]<br />
* Improve the Web platform by implementing key features and correctness fixes<br />
** finish attribute support [dholbert, jwatt]<br />
** <animateMotion> [dholbert]<br />
** fix SVG text bugs [jwatt]<br />
** tabindex in SVG [jwatt]<br />
** Unicode 5.2 [smontagu]<br />
** Sync JS and Gecko Unicode [smontagu]<br />
** missing css3-background [zwol]<br />
** calc() [dbaron]<br />
** finish up transitions [dbaron]<br />
** author control over color management? [dbaron]<br />
** SVG in images [?]<br />
** nothing selector matching [?]<br />
* Improve perceived and measured performance<br />
** opacity optimization [jwatt]<br />
** incremental bidi resolver [jfkthame]<br />
** CSS parsing performance [zwol]<br />
** lazy frame construction [tnikkel]<br />
** harfbuzz [jfkthame]<br />
** splitting overflow areas and updating overflow areas without reflow [?]<br />
** de-BRification [ehsan]<br />
* General product improvement<br />
** view hierarchy integration [roc]<br />
** zooming within display list [tnikkel]<br />
** layers (basic + retained) [roc]<br />
** plugin owned by content [?]<br />
<br />
Other ideas: text-overflow, ruby, compositor phase II</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Platform/2010-Q1-Goals&diff=188724Platform/2010-Q1-Goals2009-12-10T23:32:26Z<p>Fantasai: /* Layout */</p>
<hr />
<div>=== Layout ===<br />
<br />
* Improve the Web platform by contributing to tests and specifications<br />
** Publish CSS2.1 test suite RC [fantasai]<br />
** evaluating layout specs [dbaron]<br />
* Improve the Web platform by implementing key features and correctness fixes<br />
** finish attribute support [dholbert, jwatt]<br />
** <animateMotion> [dholbert]<br />
** fix SVG text bugs [jwatt]<br />
** tabindex in SVG [jwatt]<br />
** Unicode 5.2 [smontagu]<br />
** Sync JS and Gecko Unicode [smontagu]<br />
** missing css3-background [zwol]<br />
** calc() [dbaron]<br />
** finish up transitions [dbaron]<br />
** author control over color management? [dbaron]<br />
** SVG in images [?]<br />
** nothing selector matching [?]<br />
* Improve perceived and measured performance<br />
** opacity optimization [jwatt]<br />
** incremental bidi resolver [jfkthame]<br />
** CSS parsing performance [zwol]<br />
** lazy frame construction [tnikkel]<br />
** harfbuzz [jfkthame]<br />
** splitting overflow areas and updating overflow areas without reflow [?]<br />
* General product improvement<br />
** view hierarchy integration [roc]<br />
** zooming within display list [tnikkel]<br />
** layers (basic + retained) [roc]<br />
** plugin owned by content [?]</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Platform/2010-Q1-Goals&diff=188723Platform/2010-Q1-Goals2009-12-10T23:15:50Z<p>Fantasai: /* Layout */</p>
<hr />
<div>=== Layout ===<br />
<br />
* Improve the Web platform by contributing to tests and specifications<br />
** Publish CSS2.1 test suite RC [fantasai]<br />
** evaluating layout specs [dbaron]<br />
* Improve the Web platform by implementing key features and correctness fixes<br />
** finish attribute support [dholbert, jwatt]<br />
** <animateMotion> [dholbert]<br />
** fix SVG text bugs [jwatt]<br />
** tabindex in SVG [jwatt]<br />
** Unicode 5.2 [smontagu]<br />
** Sync JS and Gecko Unicode [smontagu]<br />
** missing css3-background [zwol]<br />
** calc() [dbaron]<br />
** finish up transitions [dbaron]<br />
** author control over color management? [dbaron]<br />
** SVG in images [?]<br />
** nothing selector matching [?]<br />
* Improve perceived and measured performance<br />
** opacity optimization [jwatt]<br />
** incremental bidi resolver [jfkthame]<br />
** CSS parsing performance [zwol]<br />
** lazy frame construction [tnikkel]<br />
* Improve core code architecture to improve stability/performance and reduce cost of future enhancements<br />
** harfbuzz [jfkthame]<br />
* General product improvement<br />
** view hierarchy integration [roc]<br />
** zooming within display list [tnikkel]<br />
** layers (basic + retained) [roc]<br />
** plugin owned by content [?]<br />
** splitting overflow areas into ink overflow and layout overflow [?]<br />
** updating overflow areas without reflow [?]</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Platform/2010-Q1-Goals&diff=188722Platform/2010-Q1-Goals2009-12-10T23:15:11Z<p>Fantasai: /* Layout */</p>
<hr />
<div>=== Layout ===<br />
<br />
* Improve the Web platform by contributing to tests and specifications<br />
** Publish CSS2.1 test suite RC [fantasai]<br />
** evaluating layout specs [dbaron]<br />
* Improve the Web platform by implementing key features and correctness fixes<br />
** finish attribute support [dholbert, jwatt]<br />
** <animateMotion> [dholbert]<br />
** fix SVG text bugs [jwatt]<br />
** tabindex in SVG [jwatt]<br />
** Unicode 5.2 [smontagu]<br />
** Sync JS and Gecko Unicode [smontagu]<br />
** missing css3-background [zwol]<br />
** calc() [dbaron]<br />
** finish up transitions [dbaron]<br />
** author control over color management? [dbaron]<br />
** SVG in images [?]<br />
** nothing selector matching [?]<br />
* Improve perceived and measured performance<br />
** opacity optimization [jwatt]<br />
** incremental bidi resolver [jfkthame]<br />
** CSS parsing performance [zwol]<br />
** lazy frame construction [tnikkel]<br />
* Improve core code architecture to improve stability/performance and reduce cost of future enhancements<br />
** harfbuzz [jfkthame]<br />
* General product improvement<br />
** view hierarchy integration [roc]<br />
** zooming within display list [tnikkel]<br />
** layers (basic + retained) [roc]<br />
** plugin owned by content [?]<br />
** splitting overflow areas into ink overflow and layout overflow [?]</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Platform/2010-Q1-Goals&diff=188718Platform/2010-Q1-Goals2009-12-10T23:02:46Z<p>Fantasai: /* Layout */</p>
<hr />
<div>=== Layout ===<br />
<br />
* Improve the Web platform by contributing to tests and specifications<br />
** Publish CSS2.1 test suite RC [fantasai]<br />
** evaluating layout specs [dbaron]<br />
* Improve the Web platform by implementing key features and correctness fixes<br />
** finish attribute support [dholbert, jwatt]<br />
** <animateMotion> [dholbert]<br />
** fix SVG text bugs [jwatt]<br />
** tabindex in SVG [jwatt]<br />
** Unicode 5.2 [smontagu]<br />
** Sync JS and Gecko Unicode [smontagu]<br />
** missing css3-background [zwol]<br />
** calc() [dbaron]<br />
** finish up transitions [dbaron]<br />
** author control over color management? [dbaron]<br />
** SVG in images [?]<br />
** nothing selector matching [?]<br />
* Improve perceived and measured performance<br />
** opacity optimization [jwatt]<br />
** incremental bidi resolver [jfkthame]<br />
** CSS parsing performance [zwol]<br />
** lazy frame construction [tnikkel]<br />
* Improve core code architecture to improve stability/performance and reduce cost of future enhancements<br />
** harfbuzz [jfkthame]<br />
* General product improvement<br />
** view hierarchy integration [roc]<br />
** zooming within display list [tnikkel]<br />
** layers (basic + retained) [roc]</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Platform/2010-Q1-Goals&diff=188717Platform/2010-Q1-Goals2009-12-10T23:00:15Z<p>Fantasai: /* Layout */ attempt at categorization</p>
<hr />
<div>=== Layout ===<br />
<br />
* layers (basic + retained) [roc]<br />
<br />
* Improve the Web platform by contributing to tests and specifications<br />
** Publish CSS2.1 RC [fantasai]<br />
** evaluating layout specs [dbaron]<br />
* Improve the Web platform by implementing key features and correctness fixes<br />
** finish attribute support [dholbert, jwatt]<br />
** <animateMotion> [dholbert]<br />
** fix SVG text bugs [jwatt]<br />
** tabindex in SVG [jwatt]<br />
** Unicode 5.2 [smontagu]<br />
** Sync JS and Gecko Unicode [smontagu]<br />
** missing css3-background [zwol]<br />
** calc() [dbaron]<br />
** finish up transitions [dbaron]<br />
** author control over color management? [dbaron]<br />
** SVG in images [?]<br />
* Improve perceived and measured performance<br />
** opacity optimization [jwatt]<br />
** incremental bidi resolver [jfkthame]<br />
** CSS parsing performance [zwol]<br />
** lazy frame construction [tnikkel]<br />
* Improve core code architecture to improve stability/performance and reduce cost of future enhancements<br />
** harfbuzz [jfkthame]<br />
* General product improvement</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Platform/2010-Q1-Goals&diff=188714Platform/2010-Q1-Goals2009-12-10T22:56:05Z<p>Fantasai: /* Layout */</p>
<hr />
<div>=== Layout ===<br />
<br />
* <animateMotion> [dholbert]<br />
* finish attribute support [dholbert, jwatt]<br />
* fix SVG text bugs [jwatt]<br />
* tabindex in SVG [jwatt]<br />
* opacity optimization [jwatt]<br />
* SVG in images [?]<br />
* Publish CSS2.1 RC [fantasai]<br />
* incremental bidi resolver [jfkthame]<br />
* harfbuzz [jfkthame]<br />
* missing css3-background [zwol]<br />
* CSS parsing performance [zwol]<br />
* calc() [dbaron]<br />
* finish up transitions [dbaron]<br />
* author control over color management? [dbaron]<br />
* evaluating layout specs [dbaron]<br />
* lazy frame construction [tnikkel]<br />
<br />
* Improve the Web platform by contributing to tests and specifications<br />
* Improve the Web platform by implementing key features<br />
* Improve perceived and measured performance<br />
* Improve core code architecture to improve stability/performance and reduce cost of future enhancements<br />
* General product improvement</div>Fantasaihttps://wiki.mozilla.org/index.php?title=Platform/2010-Q1-Goals&diff=188705Platform/2010-Q1-Goals2009-12-10T22:27:25Z<p>Fantasai: roc's layout team meeting -> create this page so we can take notes</p>
<hr />
<div>=== Layout ===<br />
<br />
* Improve the Web platform by contributing to tests and specifications<br />
* Improve the Web platform by implementing key features<br />
* Improve perceived and measured performance<br />
* Improve core code architecture to improve stability/performance and reduce cost of future enhancements<br />
* General product improvement</div>Fantasai