- From: Erik Dahlstrom <ed@opera.com>
- Date: Thu, 30 Jan 2014 17:13:45 +0100
- To: "www-svg@w3.org" <www-svg@w3.org>
Minutes:
http://www.w3.org/2014/01/30-svg-minutes.html
and as text below:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG F2F Seattle 2014 Day 1
30 Jan 2014
[2]Agenda
[2] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2014/Agenda
See also: [3]IRC log
[3] http://www.w3.org/2014/01/30-svg-irc
Attendees
Present
+1.206.675.aaaa, nikos
Regrets
Chair
Erik
Scribe
Cameron, Brian
Contents
* [4]Topics
1. [5]Resolving dates for April F2F
2. [6]should script be affected by <switch>
3. [7]deprecating/removing hasFeature
4. [8]adding SVG specific events to GlobalEventHandlers
5. [9]deprecate/remove SVGDocument.rootElement
6. [10]MPEG colored fonts meeting report
7. [11]Percentage values on objectBoundingBox for content
elements
8. [12]event handler attribute reflection
9. [13]renaming svg resize and scroll events
10. [14]scaling back features that suck performance
11. [15]a hazelnut in every bite
12. [16]it goes to eleven
13. [17]krit's keywords
14. [18]SVG2 status
* [19]Summary of Action Items
__________________________________________________________
<heycam> Scribe: Cameron
<heycam> ScribeNick: heycam
Resolving dates for April F2F
shepazu: where is it?
ChrisL: Leipzig
<ed>
[20]https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Leipzig_2014
[20] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Leipzig_2014
<ChrisL> [21]http://libregraphicsmeeting.org/2014/
[21] http://libregraphicsmeeting.org/2014/
heycam: that's 2-5 April for LGM
ChrisL: which Wednesday to Saturday
heycam: so meeting from Monday 7th April
shepazu: I have Annotations workshop in SF around that time
unfortunately
ed: how many days?
heycam: I probably prefer 4, so we can get a lot of work done
ChrisL: have we got a meeting space? has anybody approached the
university hosting the conference?
heycam: Tav is in contact with them
birtles: I agree 4 days is long but if we're taking the
time/money to get there...
... then maybe it's worthwhile
ChrisL: at that time of the year we'll be hopefully be trying
to wind up and go to Last Call for SVG2
shepazu: if we are going to have a 4 day week, I'd rather it be
at the SVG Open one when I'll be there
... how about you have a 4 day meeting, where 2 or 3 days are
the core meeting, and the final day or two is dedicated to
working days
... where you try to finish up the things resolved during the
F2F
... so people who need to leave after the core meeting can
ed: so the proposal is April 7 - 10?
krit: we should talk about who's sponsoring
ChrisL: the university would supply a room but not food
heycam: previously we've had F2Fs where we went out for lunch,
and not had catering
krit: that's OK by me
RESOLUTION: The April F2F will be April 7-10, where the 10th is
an optional stay-for-spec-editing day.
ed: how about the Graphical Web F2F?
... it's at the end of August
<ed>
[22]https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Winchester_2014
[22] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Winchester_2014
ChrisL: 27-30
<ChrisL> [23]http://svgopen.org/2014/
[23] http://svgopen.org/2014/
heycam: that's another Wednesday-Saturday
krit: regarding Leipzig, the semester holiday ends right when
we would be meeting
... so maybe it will be harder to get a room there
heycam: to get the spacing better, we should meet before
Graphical Web IMO
... would we be happy with Sat-Tue? or maybe Fri-Mon?
krit: this is a university again by the way
<ChrisL> tpac 27 Oct to 31 Oct 2014 in Santa Clara, California
heycam: if we met after Graphical Web, then we would be meeting
in September and then in October for TPAC
... so we could do it Sat-Tue before, and make Sun the optional
spec editing day or just a day off
... or Thu-Fri on, Mon-Tue on, weekend off
ed: I don't mind either
shepazu: let's decide the exact before-Graphical-Web dates
later
should script be affected by <switch>
shepazu: no
heycam: no
ed: no
ChrisL: if you were designing from scratch maybe, but given how
<script> already works now...
heycam: I am pretty sure all implementations will run script
without looking at <switch>
RESOLUTION: <script> is not affected by <switch>
<scribe> ACTION: Erik to clarify <script> is not affected by
<switch> and will be run in there, but is still disallowed by
the content model. [recorded in
[24]http://www.w3.org/2014/01/30-svg-minutes.html#action01]
<trackbot> Created ACTION-3561 - Clarify <script> is not
affected by <switch> and will be run in there, but is still
disallowed by the content model. [on Erik Dahlström - due
2014-02-06].
birtles: I don't see the point of disallowing stuff that will
work
ChrisL: it's disallowing stuff that people might have
reasonable expectations of working differently
ed: I think we should encourage people to put <script> in
<defs>
birtles: we could say authors SHOULDN'T put it in <script>
ed: I think it's fine to remove the content model restriction
but to encourage to put it in <defs>
heycam: I'm not sure of <defs>
ChrisL: part of the point of <defs> is for things which are
referenced later, and hiding from being visible, which doesn't
really apply to <script>
action updated
deprecating/removing hasFeature
krit: are we talking about deprecating or removing?
birtles: the proposal from Anne was to make it always return
true
krit: so not removing it, but deprecating and making default
return true
... if you look at the WebKit/Blink source code, we do
something with this feature
... the question is is any script using it
... given this part of our source code is outdated it's not
really reliable
... iirc, hasFeature is indirectly called by <switch>
... which doesn't mean anything, ...
ChrisL: it's one of those features that sounded good, thought
it would be the way forward, turned out it wasn't
birtles: I think we haven't deprecated it yet right?
krit: in HTML content true is always returned
birtles: I think we return proper values for it
heycam: hasFeature is defined in DOM btw
ChrisL: it was never clear if you needed to support 100% of a
feature to return true
birtles: now with things like modernizr...
krit: did someone add a use counter for hasFeature?
birtles: a few days ago someone did I think?
<ed>
[25]http://code.google.com/p/chromium/issues/detail?id=335301
[25] http://code.google.com/p/chromium/issues/detail?id=335301
shepazu: in DOM 3 Events we come up with a logical way to make
hasFeature work
... for fine grained control for reporting
... which was roundly rejected by anne and others
... which is expensive and other things which are not feature
testable
<birtles> the usage counter has been added to blink:
[26]http://lists.w3.org/Archives/Public/www-svg/2014Jan/0053.ht
ml
[26] http://lists.w3.org/Archives/Public/www-svg/2014Jan/0053.html
shepazu: I won't get in the way of removing it, but I think
it's being done on outdated data
<birtles>
[27]https://code.google.com/p/chromium/issues/detail?id=335301
[27] https://code.google.com/p/chromium/issues/detail?id=335301
shepazu: I've had conversations with Paul Irish about testing
whether certain SVG features are available, and there weren't
Rossen_f2f: can't you piggyback off @supports for this?
shepazu: I don't mind
birtles: I think it's not going to work when there are bugs in
the features that are being reported as true
... which you often want to test for
ChrisL: it's not can I rely on this feature, but can I rely on
a subset of this feature that I'm using right now?
... you're really saying if I use this in this way, in
combination with this other thing, ...
shepazu: feature detection won't work for that either
Rossen_f2f: why wouldn't feature detection work?
shepazu: it can't test for rendering things
birtles: Safari on iOS 5 for example paints patterns upside
down
... for that you really need to do UA string checking
... so I think that's an advantage of feature testing, you can
test for exactly what you need
ed: should we wait for the use counter results?
... I wouldn't mind if we returned true all the time
Rossen_f2f: you're trying to do implementaiton detection
through feature detection
... which doesn't seem to be exactly what feature detection is
for
... if you want to detect "what is the rendering of something"
...
krit: there's a difference between supporting a property and
supporting it in the rendering pipeline
Rossen_f2f: your @supports or hasFeature should still return
false in this case
... I'm with Doug that hasFeature and feature detection are
useful and good to keep
... still people are building solutions on top of this can impl
versions of their apps that are best for that feature set
krit: if you ask "do you support filters"? you might return
true, even if you don't support all filter inputs
sgalineau: that's true, but that's not an argument for not
doing it at all
... that's why @supports gives you the ability to check for
property values
birtles: I'm just not sure you ever get enough granularity
... for animations, you could even test the supported values,
like syncbase values, but you don't know if it supports cyclic
dependencies
shepazu: but you could add feature detection for specific cases
like this
... but for other cases you wouldn't need to
... pdr just said 10% of pages use SVG, which is misleading
because a lot of that is Modernizr
krit: there is a thing where you can select which features to
check for, so not all Modernizr uses will end up creating an
SVG element
shepazu: but people will use it poorly
... the case where you inject SVG because you might use it, is
different from doing it for feature detection
... I think the pattern of having to download scripts that are
getting increasingly large, as there are more features added to
the platform
... and putting the onus on authors to find some feature
detection system that is a good tradeoff between what's
actually supported and what's not supported,
... I think that's us being lazy and harming authoring
sgalineau: that's why we have @supports
Rossen_f2f: at the end of the day, it's a poor man's
implementation of reflection
... and reflection is useful
shepazu: maybe hasFeature is not the right place to do this
... I'm suggesting we should have reflection at all levels of
the stack
... we can remove hasFeature, but let's not say we don't need
the functionality, because we do
ed: let's postpone until we get the use counter results
adding SVG specific events to GlobalEventHandlers
krit: was the editor of the spec with this interface had a
chance to look at it?
ed: Boris Zbarsky replied
<ed>
[28]http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-Ja
nuary/041909.html
[28]
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-January/041909.html
onbegin, onend, onrepeat, onzoom
ed: I'm proposing we don't add onbeing/onend/onrepeat
... for SVGZoom I'm not sure about it
... we could remove the prefix
ChrisL: would it conflict it with current work on defining
zoom?
ed: relatedly I also posted a patch to Blink to add the global
event handlers
... so you assign to .onclick on SVG elements
heycam: what are we doing about zoom event altogether?
... did we discuss getting rid of the "SVG" prefix?
ed: we did, for those that have existing counterparts
... so that's all the events except for SVGZoom
krit: zooming is being discussed in CSSWG
<ed> and endEvent/beginEvent/repeatEvent
krit: should we check what the outcome of that is first? before
we add a global onzoom?
ed: it doens't need to be resolved right away
... I don't think SVGZoom is used much
birtles: can we drop it even? or is it used?
ed: it's something people have asked for
... for UIs zooming and panning
Rossen_f2f: I strongly suggest waiting for what Ted comes up
with in CSS
... the one thing we need to figure out is what we really need
from a zooming feature
... [mentions various possible zoomings]
... my hope is that once they're done defining the behaviour,
the CSSOM will follow with the appropriate events for that
heycam: so given .onzoom isn't supported anywhere, let's not
add it now
... and wait to see what broader zoom events come out of the
CSS work we can align with
[look to see how things are done in HTML]
ed: so let's put .onbegin, .onend, .onrepeat on
SVGAnimationElement
heycam: ok
RESOLUTION: We won't add an onzoom IDL attribute, but we will
add onbegin, onend, onrepeat to SVGAnimationElement.
<scribe> ACTION: Erik to add onbegin, onend, onrepeat to
SVGAnimationElement. [recorded in
[29]http://www.w3.org/2014/01/30-svg-minutes.html#action02]
<trackbot> Created ACTION-3562 - Add onbegin, onend, onrepeat
to svganimationelement. [on Erik Dahlström - due 2014-02-06].
-- 15 minute break --
<Tav> How do I call in?
Tav, see /topic
<Tav> heycam, Thanks
<Tav> OK
deprecate/remove SVGDocument.rootElement
ChrisL: do it
heycam: I asked, should we add use counters?
ed: they've been added now, we'll have to wait a couple of
weeks to get results
... I still think we should mark it as deprecated in the spec
birtles: I think we can mark it as deprecated, the results are
useful for knowing when to remove it
heycam: which might be immediately?
birtles: might be!
ed: this came up in a discussion with implementation for DOM 4,
where we have a new XMLDocument interface, which is kind of
used to replace SVG document
RESOLUTION: We will deprecate rootElement in SVG 2.
<scribe> ACTION: Erik to mention in SVG 2 that rootElement is
deprecated. [recorded in
[30]http://www.w3.org/2014/01/30-svg-minutes.html#action03]
<trackbot> Created ACTION-3563 - Mention in svg 2 that
rootelement is deprecated. [on Erik Dahlström - due
2014-02-06].
MPEG colored fonts meeting report
ChrisL: there was an SVG glyphs in OpenType group that
discussed how to do this
... consensus was reached finally and we came up with a
proposal that said how to do this
... backed up with an impl in Firefox
... Adobe was heavily involved in this, and has been making
fonts, demos and promoting it
... this was good, and MPEG who do the ISO version of OpenType
due to a strange historical accident, would do this for the 3rd
edition
... they put out a call for proposals
... they were aware of four things going on
... one by Apple, who decided not to submit it (or document it)
... one by Google, which is a bunch of PNGs
... (currently OpenType supports rasters but only black and
white)
... the PNGs can be different sizes
... that hits the emoji case closely
... MS had a different proposal which builds on TT rasterising
... outlines that can be hinted etc., but you can have multiple
of them that can be stacked, and you have a palette to say what
colours the layers have
... so you can do flat solid colour things
... can't do gradients, transparency, masking, filtering, etc.
... at the same time, for typographers that like things to be
hinted, that seems a win
... then there's the SVG proposal, which uses secure animated
mode, so there's no scripting, interaction
... but you can use any graphical support in SVG
... it doesn't use SVG Font's <glyph>
... we did some pre-harmonisation work with the MS proposal
... so we use the same palette information in the font
... that was seen as a good thing in the meeting
... typically the outcome of MPEG meetings is a competition
... and decide on a winner, then the winning company has to
provide a reference impl
... each proposal was seen as having benefits/drawbacks, so the
proposal is to stick them all in
... and the typographer can choose which to use
... we already have that with TT vs CFF outlines
... which also exposes a problem, because in OT2 you have to
say which you're using
... if we're adding 3 more formats, that's obviously not going
to work
... so they're fixing that bug
... the other thing was a call for some math tables that let
you do equation typesetting
... the MS proposal, the only one, was accepted
... Vlad will incorporate the proposals and circulate a draft
shepazu: what's the IPR policy on this?
ChrisL: the IPR policy for the SVG glyphs in OpenType part was
decided by the Community Group, and almost everyone has signed
off on that
... so that's RF
shepazu: anyone significant hasn't?
ChrisL: Canon has not
... the policy for ISO as a whole is RAND, and all you have to
do is say that you will give a license
... companies discuss about reasonable is
... not super happy about that
... but that's how it works
... at least for the SVG parts it's ok
shepazu: what about for OpenType itself?
ChrisL: there have been patents, e.g. the hinting stuff
... the other thing is that unlike most ISO groups, this one
does publish the spec openly
... which is good except you still have to click through a
licence
... in practice everyone refers to the MS version
... I spoke to Michelle from MS and assured me once the
document was stable she'd incorporate it into the MS version
... some people were worried about the SVG one, and it
transpired the reason why is that it would be an MPEG bake off
... and one would win, others would lose
... I'm doing a talk at LGM about this
... I'm starting to look at the impl landscape, most of which
work on windows, some on mac, none on linux
... which let you edit various things
... there is some momentum though
... there is interest in doing it too
... the type industry which has traditionally sold sets of
fonts that align, is understanding that that sucks as a
workflow, and wants to have a single font with tables
... another worry about SVG was that the colours were fixed, so
hearing that we had this palette mechanism, they were super
happy
... as far as MPEG is concerned, they're at a given stage, but
at some point in the future there will be votes and will become
a standard
... no need for implementations like CR
... so it would be good to have in another browser, and also
authoring tools
... demos made by typographers would be good too
... inkscape has already got a way to do SVG glyphs, which are
going away, and wraps them up and produces a font
... would be good to repurpose that for SVG in OpenType
Tav: I know there'll be a lot of FontForge people at LGM
ChrisL: yes, though FF is a bit funky given its interface
... plus if you're running it on a mac you need to run X
... there was an effort to split FF into two parts, a library
then a UI, that has not happened
... would be good to talk to Scribus people too
... one thing you can do with this, video games use a lot of
coloured signage, icons, and you can have huge assets for this
... and recolour them etc.
... having a coloured font format for slotting different
palette values, is a win
... and the 3D people use fonts
<ChrisL> for amazing title sequences
shepazu: is there a possibility to co-publish this as a W3C
spec?
ChrisL: the whole of OT3?
... there's a possibility, but MS does own the non-ISO version
of the spec, so not sure what they would say about that
<ChrisL> [31]https://www.microsoft.com/typography/otspec/
[31] https://www.microsoft.com/typography/otspec/
ChrisL: there's a bad redirect there for the licence
shepazu: I think there could be some value at republishing at
W3C
... second question is, since we are killing off SVG fonts, for
those browsers who decided to never do SVG fonts, that's good
news
... there's a chance we'll see this new SVG glyphs in other
browsers since they already do OpenType
... with the shitty internationalization of the old SVG Fonts,
it was reasonable for them not to implement it
... what I hated about SVG Fonts was the inverted coordinate
system
... is there any possibility for us resurrecting SVG Fonts in a
way, by embedding an OpenType font in the document?
ChrisL: the XML serialization of OT, UFO, is very verbose
... the binary format is very compact, lots of tables with
bytes
... by the way, WOFF is a way to wrap up any sfnt font
Tav: would it be possible to have the table information in the
font, but feed in the SVG glyphs to it?
ChrisL: that would be interesting
... there is a demo of that, but it's kind of hacky
... roc made it. you load in an OpenType font, and gives you a
textarea to enter some SVG, wraps it up and sticks it into the
table, generates an OpenType font
Tav: I tried to do this with inkscape, but I ran into trouble
since we use Pango for text layout, which doesn't let you
insert a user font
... I was going to intercept the layout information from Pango,
and just draw the SVG glyph
ChrisL: I should say, Behdad Esfabod has been at these meetings
and is aware of this
... and is interested in adding this to Harfbuzz
shepazu: maybe not right now, but this is a useful use case to
pursue in the future
Tav: yeah. it's a way of getting your cake and eating it too.
... basically saying OpenType handles all the nasty i18n layout
stuff, and we provide a glyph
ChrisL: one thing people brought up was that they've looked at
SVG for the first time, and noticed that SVG has text in it
... what if text has fonts on it
... do you have a glyph with the same font?
... and they've followed the CSS2 reference and thought you
need to support all the old font formats
... but there is a possibility we might be asked down the line
to produce a subset for SVG for this
... maybe we shouldn't prompt this, but if asked we should
shepazu: if it's well in the scope of Integration...
ChrisL: integration is already being referenced for secure
mode, secure animated mode
<shepazu>
[32]http://lists.w3.org/Archives/Public/www-svg/2014Jan/0039.ht
ml
[32] http://lists.w3.org/Archives/Public/www-svg/2014Jan/0039.html
shepazu: I had a conversation with the guys from Decotype
... they were asking about SVG fonts, told them about groovy
fonts
... they're trying to do arabic
ChrisL: they also talked to me, and they're basing their stuff
on altGlyph
shepazu: I told them it's going away, and they said oh that's
not a problem, we can do it another way
... but their use case is, the groovy font use case
... and it ties in to wanting to have shape selection in SVG
... I'd like to talk to you guys about ramifications of that
... the idea of being able to select shapes as well as text
... I don't know the UI for that, or care
... but we should say when something is selected
... this could also play into copy and paste of graphics, and
annotations
... and that would feed into groovy text as well
[doug draws groovy text on the board. again!]
ChrisL: maybe we should send a liaison statement to MPEG SC29
WG whatever
<scribe> ACTION: Chris to send Cameron an email with details on
how to send a liaison statement to MPEG about SVG in OpenType
[recorded in
[33]http://www.w3.org/2014/01/30-svg-minutes.html#action04]
<trackbot> Created ACTION-3564 - Send cameron an email with
details on how to send a liaison statement to mpeg about svg in
opentype [on Chris Lilley - due 2014-02-06].
<ChrisL> [34]http://letterror.com/fontcatalog/ltr-federal/
[34] http://letterror.com/fontcatalog/ltr-federal/
<scribe> ACTION: Cameron to propose something for marking up
graphics with equivalent text [recorded in
[35]http://www.w3.org/2014/01/30-svg-minutes.html#action05]
<trackbot> Created ACTION-3565 - Propose something for marking
up graphics with equivalent text [on Cameron McCormack - due
2014-02-06].
ChrisL: there are different optical sizes, but they're
different fonts, for the filling of the "No" glyphs
... we should support that using media queries in
SVG-in-OpenType
... but it's not quite possible yet, we don't yet have an
appropriate MQ to do this
heycam: this is related to the zoom MQ that Takagi-san wants
... we should work out what we need for this and give input to
Ted etc. who are looking at zooming
Percentage values on objectBoundingBox for content elements
<ed>
[36]http://lists.w3.org/Archives/Public/www-svg/2014Jan/0081.ht
ml
[36] http://lists.w3.org/Archives/Public/www-svg/2014Jan/0081.html
ed: I think most people who responded to the mail said they
preferred percenteages to be relative to the object bounding
box and not the viewport
krit: I think it should be oBB relative because browsers do
bounding box dimension relative to the viewport dimension
multiplied by percentage of viewport
... which is very confusing
... all browsers do that, that's interoperable behaviour
Tav: Batik and Inkscape does it too
krit: the specification says something different
heycam: do you reckon anyone relies on it?
krit: Illustrator partly, some examples do rely on what the
spec says [i.e. different from impls]
heycam: and what does the spec say?
krit: it should be a percentage of the viewport
... this is when you say maskContentUnits="objectBoundingBox"
Tav: it's kind of strange that the mask would move when you
widen the SVG
krit: yeah
ed: how much content would break?
krit: people don't tend to use percentages here, because they
don't understand the behaviour, and use 0..1 instead
Tav: Inkscape doesn't generate using % objectBoundingBox values
heycam: do we have tests in the test suite which support the
current weird behaviour?
krit: don't think so
heycam: I think I'd be ok to be the guinea pig to try changing
the behaviour here and see if we get any bugs
<cabanier_> Illustrator import would break since they resolve
percentages wrt the viewport
<Tav>
[37]http://tavmjong.free.fr/SVG/BOUNDINGBOX/reference_box.svg
[37] http://tavmjong.free.fr/SVG/BOUNDINGBOX/reference_box.svg
Tav: not sure the spec is clear whether transforms on ancestors
of these resource elements should be taken into account
ChrisL: if there's specific wording in the spec you should
suggest that
... we should add an example in test suite for that too to file
a bug on rsvg
<scribe> ACTION: Tav to think of text to clarify whether
transforms are taken into account with % objectBoundingBox
values in resource elements [recorded in
[38]http://www.w3.org/2014/01/30-svg-minutes.html#action06]
<trackbot> Created ACTION-3566 - Think of text to clarify
whether transforms are taken into account with %
objectboundingbox values in resource elements [on Tavmjong Bah
- due 2014-02-06].
-- lunch break --
<ChrisL> scribenick: chrisl
event handler attribute reflection
ed: need wording to replicate what html5 has abour reflection
in IDL and on-* attributes
heycam: yes we do
ed: reference html5 directly
ChrisL: yes, unless its super specific
<scribe> ACTION: erik to add ref to html5 for attr reflection
[recorded in
[39]http://www.w3.org/2014/01/30-svg-minutes.html#action07]
<trackbot> Created ACTION-3567 - Add ref to html5 for attr
reflection [on Erik Dahlström - due 2014-02-06].
renaming svg resize and scroll events
ed: html5 has resize and scroll events, not exatly same as svg
which is specific to a fragment
(checks)
ed: resize is targetted to rootmost svvg element
heycam: (what about namespace boundaries)
only within an svg document fragment
krit: what is it for object or embed
heycam: the same
... suprised if people are listening to svg resize on outer
html
krit: relative sized inline svg, change window size
heycam: no need to worry about svg fragments in html inline.
probably listening on html doc at the top or on window
shepazu: unless we find somethin unliveable users will find a
way to do this
... do what hytml does. but new editor is not unfamiliar with
svg and will understand the use cases
... if we need changes we should say
heycam: not aware of anything needing to change. renaming is ok
... try it and look for breakage
ed: exposed on html body and window
<ed> The onblur, onerror, onfocus, onload, onresize, and
onscroll event handlers of the Window object, exposed on the
body element, replace the generic event handlers with the same
names normally supported by HTML elements.
<ed> (from html5)
ChrisL: so change body to body or svg
heycam: they are actually listening to windopw
ChrisL: we need to say they are exposed on svg element also
ed: same for load event on window
... already have some wording for load events to make svg roots
behave like body
<ed> The ‘svg’ element exposes as event handler content
attributes a number of the event handlers of the Window object.
It also mirrors their event handler IDL attributes.
<ed> (from svg2)
ChrisL: so same wording for the others
heycam: "a number" is vague
ed: links to html5 to list them
<ed>
[40]https://svgwg.org/svg2-draft/struct.html#SVGElementEventHan
dlerAttributes
[40]
https://svgwg.org/svg2-draft/struct.html#SVGElementEventHandlerAttributes
ed: need to explicitly list them
resolved: remove svg prefix on svgresize and svgscroll events
action erik to remove svg prefix on svgresize and svgscroll
events
<trackbot> Created ACTION-3568 - Remove svg prefix on svgresize
and svgscroll events [on Erik Dahlström - due 2014-02-06].
scaling back features that suck performance
heycam: hearing about wanting to better handle conent on lower
performance machines
... working out what to do. if hardware is there and the
machine is slow, it works but at low fps
... several approaches to make the websites less beutiful but
functional and responsive
ChrisL: do you have specific things that slow down
heycam: no its across the whole stack
... one approach is to come up with out own hueristics to scale
back features, things to turn off
... eg filters, reduce rendering or switch off
... can conformance be relaxed to codify that
... do people think there are particular features to scale back
ChrisL: worried about relaxed conf criteria being also taken as
the typical rendering
<ChrisL> heycam: hearing about wanting to better handle conent
on lower performance machines
<ChrisL> ... working out what to do. if hardware is there and
the machine is slow, it works but at low fps
<ChrisL> ... several approaches to make the websites less
beutiful but functional and responsive
<ChrisL> ChrisL: do you have specific things that slow down
<ChrisL> heycam: no its across the whole stack
<ChrisL> heycam: one approach is to come up with out own
hueristics to scale back features, things to turn off
<ChrisL> heycam: eg filters, reduce rendering or switch off
<ChrisL> heycam: can conformance be relaxed to codify that
<ChrisL> ... do people think there are particular features to
scale back
<ChrisL> ChrisL: worried about relaxed conf criteria being also
taken as the typical rendering
* Disconnected (No such device or address)
ChrisL: in games is miostly user selected
Rossen_f2f: if this is done by the user agent, afraid there
will be fast disparity between implementations depending on
internal efficiency
... so you get great disparity on the same device
... if they are automatic
... if the policy is across all devices they can be automatic
(low medium high) as long as they are defined exactly what
happens
... and user must have right to override that
shepazu: could be user agent dependent
heycam: to decide what to scale back, 2 approaches: spec what
it means, or author indicates disposable features and priority
ChrisL: authors will do what works on their UA, not test on
otyhers
Rossen_f2f_: ask performance wg about this
krit: uas cvary so affect uas differently. does not necessarily
help
heycam: uas will auto adjust based on actual performance
krit: not opposed to performance profiles
Rossen_f2f_: same her, as long as testable and results will not
vary by user agent at the same level on the same device
... figure out if it makes sense to sacrifice filters in medium
or not (varies by UA)
... it will be sacrifice for sure
birtles: if i have something with gpu optimisation, want to use
that
heycam: would not want to force user intervention
... bad to cripple the better implementation
krit: use media queries for this
... author can decide what is important for high quality
birtles: cant be entirely author device because many authors do
not test widely
heycam: bad to reduce functionality on a device that can do it
ChrisL: have low medium high auto where auto scales by fps
shepazu: engage with Khronos (webgl guys) about performance
levels
... perfomance based characteristics. also did openvg
... willing to work with us. identified as a liaison item
Rossen_f2f_: can argue both sides
... on mobile, browser defines the experience. need to get best
experience possible on that device
... also depends on the competition
heycam: now they can get different performance experience
Rossen_f2f_: will also give behaviour changes
shepazu: can we have best and worst levels for each feature
... say 2 uas on same hardware, one has hw accell on one thing
is worse on something else
... so it would be predictsable what level it goes to
... level of service knocked out is independent
Rossen_f2f_: so a minimum bar not an absolute bar
shepazu: yes, and per feature
... so it is predictable
heycam: that specificity would be good
... so there is a combinatorial explosion of profiles
shepazu: maximises experience for user and author, also allows
ua to compete on performance while still being predictable at a
given level
heycam: even if it is continuous, can reduce filer resolution
for example, or should it be discrete
shepazu: three levels
Rossen_f2f_: low medium high
heycam: imagine we discover that continuous perf improvement on
filters with lower scale bitmaps. should they be allowed to
vary or mnust they drop down to a discrete level
shepazu: best is "do this or better"
heycam: is that performance or rendering behaviour?
shepazu: we set a minimum bar
Rossen_f2f_: some impls could not make that
Smailus: what defines what is in the profile, it changes over
time
Rossen_f2f_: if we have them, how does it benefit the content
author to develop over device evolutions
... ua gets a better impl on the same device
... how would the content start to take advantage of that
heycam: was thinking author would get perf benefir of scaling
back features by defining how operations are done, including
ignoring features
... not @media low-perf
... so when the usa meets te bar it uses high perf mode
krit: these were requested four years ago already
... sometimes a drop shadow is purely decoration and you drop
it
Rossen_f2f_: media queries f=to get the current perf level
krit: what if you still are too low perf. can you drop features
heycam: what if you are medium level then set properties that
use higher perf features
... worry about author access to perf tweaks because they age
badly
Rossen_f2f_: hard to define the matrix of allowed capabilities
heycam: dont want to do that per device
... want it done automatically
Rossen_f2f_: some devices will be "always high"
heycam: dont want to test on lots of devices to get the perf.
want guidelines on how to tel lif perf is inadequate
ChrisL: is perf mai=nly in terms of fps
heycam: yes
... can always have ginormous files, stil lwant to auto scale
back for that
shepazu: suggest we say its interesting buf not define today
krit: not going anywhere concrete
shepazu: open to proposals
a hazelnut in every bite
it goes to eleven
krit's keywords
krit: (daws pretty pictures which we neglect to capture)
bounding box of a stroke where there is dashing, taking into
account miter limit, where the dashing does not cover the
corner
three options 1) actual painted area 2) geometric 3) maximal
with miter limit and stroke geometry
Rossen_f2f_: makes sense when ther is fill, not without
krit: depends on miter limit
birtles: and line cap
(we don't want bounding box to oscillate if a dashed stroke
animates start position)
heycam: for beziers the exact tightest bound is expensive and
not worth it eg for a repaint region
cabanier_: mostly you want loose bounds
... make it as fast and loose as possible
(discussion on getting data back from gpu)
(which is hard and slow, by the way, and endlessly fascinating
as a conversational topic)
cabanier_: you get the box you need stroking
heycam: can stroke with transparent paint, or compute in
offscreen buffer
shepazu: does anyone disagree with 3
cabanier_: option 4 is convex hull of control points
heycam: really want to avoid the marching ants problem
birtles: if someone animates miter limit
(no one really does)
shepazu: asks about vector effects
ChrisL: no implementor interest unfortunately
cabanier_: should be a more precise version too
shepazu: add several ones
Rossen_f2f_: over engineering
heycam: we should be doing that (markers, stroke, etc etc)
krit: css gradients on object bounding box. only covers half
the stroke!
... so we need something better
... choose stroke outline instead, for a decorated bbox
Rossen_f2f_: exactly like semi transparent dashed borders over
background
heycam: bbox of control points, can we do same for stroke and
say ignore dashing
krit: backend engine needs to do it twice, once without dashing
... better to just look at points without rendering
cabanier_: only fails with stupid miter limits
krit: can happen
heycam: polygon with exact points, stroke width 10px, what do
you do
krit: miter limit on slallest angle, add miter limit ...
heycam: ignore ML. calc disatnace from lime by stroke width
... same as doing stroke path operation, same maths
krit: so we need to do it twice
heycam: fudge factor to pad convex hull bbox, proportional to
stroke width
ChrisL: added onto the four sides of the chull bbox
<nikos> oops
shepazu: people would find it counter intuitive
krit: yes, now i am convinced on 3
3 3 3 3 3 4 2 4 4
cabanier_: perf will be really slow
Rossen_f2f_: 3 on high, 4 on low ...
shepazu: want to see some perf metrics and see how inaccurate 4
is
cabanier_: illustrator uses 4 for selection hilight
heycam: add an issue in the spec
shepazu: they will do the easiest one
Rossen_f2f_: the most performance one
shepazu: how often is bbox called
heycam: for this new one, not at all :)
krit: stroke bbox is in blink, not activated, gets used a lot
birtles: in future decorated bbox will be called a lot
krit: problem if filling with image, missing some pixels due to
inaccuracy
ChrisL: image size for the fill should not be affected by the
exact position dashes fall
<heycam>
[41]https://hg.mozilla.org/mozilla-central/file/6f544aa66c1a/la
yout/svg/nsSVGUtils.cpp#l1000 is what we use to work out an
upper limit for the bbox of a stroked shape without actually
calculating the stroke shape
[41]
https://hg.mozilla.org/mozilla-central/file/6f544aa66c1a/layout/svg/nsSVGUtils.cpp#l1000
heycam: our calc for repaint region ignores miter limit, just
stroke width
... so pad bbox by half stroke width
<heycam> the input to that function is the bbox of the geometry
that has already taken miter limit into account
<heycam> or miters into account
zakim?
nikos, call into zakim plz
krit: one dash on an ellipse ....
<heycam>
[42]http://lists.w3.org/Archives/Public/www-archive/2014Jan/001
4.html
[42] http://lists.w3.org/Archives/Public/www-archive/2014Jan/0014.html
<heycam> ^ picture
krit: want to add both methods to the spec and add an issue
shepazu: representing authors and users. informed decision
needs data
birtles: best to gather data as we implement
shepazu: ask the community, give the tradeoffs perf and
precision
krit: not happy, does not help until they implement so defers
shepazu: option3 won the vote
... put issue saying maybe 4
... spec can be referenced at any level as long as the portion
is stable
(process explanations of stability criteria)
action krit to add decorated bbox option 3 to svg2 with issue
explaining option 4
<trackbot> Created ACTION-3569 - Add decorated bbox option 3 to
svg2 with issue explaining option 4 [on Dirk Schulze - due
2014-02-06].
break
<heycam> -- 15 minute break --
<birtles> Scribenick: birtles
<scribe> Scribe: Brian
SVG2 status
heycam: one concrete thing I'd like to discuss is out new
cut-off date
... at TPAC we thought we needed more time
... so we extended it from the end of last year
... so we need a replacement date
birtles: what is left?
<heycam>
[43]https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_C
ommitments
[43]
https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Commitments
heycam: let's see what's left per-person
<heycam> trackbot: close action-3271
<trackbot> Closed action-3271.
heycam: starting with Doug
... 19 - level of detail -- covered by zoom media queries which
Takagi-san has been looking into and we are waiting on Ted's
investigation into
... Cameron will mark this one yellow
... 20 - InkML trace groups -- covered by variable-width stroke
... 40 - Catmull-Rom curves - keep it
... 41 - Regular polygons and stars - keep it, work with Tav
Doug: 47 - flip-invariant text - keep it, need to talk to
others
... 52 - Tooltip - keep it, Dirk interested
... 91 - Bounding box text, Dirk to take
... 93 - content editable - Doug will look at another way of
looking at editing markup but possibly not part of SVG2, remove
heycam: unless you want to define how it should work if you
have contentEditable on an ancestor HTML element
shepazu: you should be able to edit the text
heycam: we need to define that
Doug: 100 - Support for key events from DOM level 3 events
krit: didn't Rich ask about referencing DOM4?
heycam: yes, I think he referenced DOM3 in the end
Doug: close this issue, stuff has already happened in the spec
... 128 - define how border and background apply to SVG, keep
it
... 129 - outline property, keep it
... 130 - clarify how pointer-events can hit the root SVG or
not, Erik to take
Chris: 28 - color management, closed
... 30 - non-scaling features (e.g. rectangle corners)
krit: we don't want to extend that, we found too many issues
with this
... defer it
ChrisL: 48 - deprecate xml:space and use CSS white-space
heycam: give the CSS part to Tav who is rewriting the text part
ChrisL: 62 - linear interpolation for some properties which are
currently discrete only -> pass to Brian
... 66 - remove requirement for width/height from foreignObject
(discussion about whether this is possible and if we should do
it for foreignObject only)
ChrisL: it's a fairly simple fix for this case, I think
krit: I don't know that it is
heycam: if there's HTML content inside use the shrink-wrapping
algorithm to work out the size
... it's like the minimum width that doesn't break a line, or
something like that
... it's what you use with absolute positioning
ChrisL: I'll do it
... 70 - CSS3 Color syntax - done
... 73 - Align CSS Value and Units
heycam: I think I aligned some things but I haven't added new
units etc.
... I'm happy to take it
ChrisL: it's yours
... 76 - allow clip to reference any element
krit: clip property is now deprecated
<ed> [44]http://www.w3.org/Graphics/SVG/WG/track/issues/2355
[44] http://www.w3.org/Graphics/SVG/WG/track/issues/2355
heycam: that should actually be clip-path
krit: this is actually now part of CSS masking
... but it won't be in the first level
... give the action to me
(make it yellow)
(means "handled in another spec")
ChrisL: 82 - WOFF support - done
... 89 - viewport-fill(-opacity) / background-color
(discussion about whether viewport units can be used to cover
the use cases for this feature)
scribe: keep it
... 92 - improved text re: characters/glyphs/selection etc.
heycam: Tav is reworking a lot of text stuff now so it might be
worth waiting to see what he's done
ChrisL: I'll do it if he hasn't
krit: add Tav's name to 92
ChrisL: 115 - currentFillPaint, currentStrokePaint - done by
heycam
... 119 - Use updated CSS3 specs - heycam to do
... 126 - Require SVG Tiny fonts - no, close with no action
... 127 - Make CSS mandatory - keep
... 131 - xlink prefix for href
krit: I already defined this in CSS Masking
ChrisL: I'll copy it from there
krit: either there or filters
ChrisL: 138 - allow masks to use alpha/luminance both - covered
by CSS Masking
... 140 - masks pointing to mask elements only - covered CSS
Masking + element()
heycam: 1 - Backwards compat note - skip it
... 9 - markers done
... 10 - fix DOM, ongoing
... (lots of items done, good work Cameron!)
... 25 - data-* attributes, keep
... 26 - HTML5 global semantic attributes - keep it, need to
check what is in HTML
... 27 - make property values case insensitive - I might have
done it, need to check
... 33 - stroke dash adjustment - keep it, I'll see what I can
do
... 36 - align the style element with the HTML5 style element,
keep it
... 45 - glyph baselines
... the text chapter will reference CSS text for this
... keep it
... 49 - transforms on tspans - keep it
<scribe> ACTION: Cameron to write spec text on transforming
tspans [recorded in
[45]http://www.w3.org/2014/01/30-svg-minutes.html#action08]
<trackbot> Created ACTION-3570 - Write spec text on
transforming tspans [on Cameron McCormack - due 2014-02-07].
krit: does this belong in CSS transforms?
... if so please notify www-style
heycam: do you list applicable elements in CSS Transforms?
krit: yes
heycam: ok, I'll do that then
... 54 - Support HTML document-wide events and make sure they
apply to SVG document, keep it
... 57 - async and defer on script elements
... at first I thought this was a good idea but others
including Hixie actually thought there was lots of craziness in
HTML we don't want that
... keep it, possible drop it
... 69 - positioning information in MouseEvents, keep it
... 74 - deprecate baseline-shift, vertical align, keep it
... 80 - DOM method to convert <text> to outline path data
cabanier_: that's part of the Canvas path API which is separate
to Canvas
heycam: but the requirement is to get actual path data
... so I can actually manipulate the path segments
cabanier_: that might not be available then
... it might be possible
... it lets you get an opaque pointer to the outlines that you
can do operations on it but not individual segments
... keep it
... 108 - inline scriptable content, keep it
... 109, 110 - more script stuff, keep it
... 118 - CSS3 definitions for text, keep it
... 121 - Move events to Element
... nothing to do (Hixie says no)
... 122 - Path rotation command - done
... 123 - Introduce evt as alias to event, give it to Erik
... 124 - object-fit, object-position, keep it
... 132 - remove restriction on tref, done
krit: does tref still exist?
heycam: in any case, it's already done
<ed> [46]https://svgwg.org/svg2-draft/text.html#TRefElement
[46] https://svgwg.org/svg2-draft/text.html#TRefElement
birtles: 14 - fix path APIs, keep it, might still be needed
depending on how DOM improvements go
... 96 - synchronization, make yellow (Web Animations)
... 111 - Changes to animation, move to Animation Elements spec
(yellow)
krit: 51 - video in SVG, Takagi-san did this already
... 75 - captions for video, Takagi-san did this too
... 139 - canvas in SVG2, Takagi-san did this too!
... 21 - transform on the <svg> element, keep this
ed: 29 - non-scaling stroke, done
... 55 - drag&drop, we have the global event handlers
heycam: we need to add a sentence to say this works in SVG
ed: will do
... 71 - image-fit, this is now object-fit which Cameron will
do
... 87 - buffered-rendering, done?
heycam: now that we have will-change do we need it?
ed: we could reconsider it?
... it's not the exact-same thing
heycam: let's discuss this in a telcon later
... 88 - vector-effect, this is non-scaling stroke, done
<heycam> ISSUE: should we have both buffered-rendering and
will-change?
<trackbot> Created ISSUE-2452 - Should we have both
buffered-rendering and will-change?. Please complete additional
details at
<[47]http://www.w3.org/Graphics/SVG/WG/track/issues/2452/edit>.
[47] http://www.w3.org/Graphics/SVG/WG/track/issues/2452/edit%3E.
heycam: 116 - focal point for radial gradients, done by Dirk
... 117 - fr attribute for radialGradient, done by Dirk/Tav
... 125 - text-overflow, done
... 126 - SVG Tiny fonts, no longer needed
cabanier_: 20 - variable-width stroke - will discuss tomorrow
heycam: only others are Tab, Tav and Cyril
... for Tab, z-index
(discussion about whether to keep it or not)
scribe: keep it for now
... Cameron to look into it
42 - arc in paths in easier
heycam: I partly addressed this with the bearing commands
... we discussed adding all the canvas arc commands to SVG but
I'm not sure
... assign it to Rik
89 - This is just Chris now
6 - namespace requirements, add Dirk
8 - shadow tree, add Dirk
39 - shared path segments, leave it with Cyril
95 - animation element, covered by iframe work done by
Takagi-san
135, 136 - done in SVG2, Brian to remove from here and add to
Animation Elements
137 - playbackOrder - Brian to remove from SVG2 and maybe add
to Animation Elements
We'll cover Tav's items tomorrow
heycam: those items without names associated we will not do
since no one is interested
birtles: so can we now estimate our next deadline?
heycam: we should have a cut-off date for new features and then
allow a few months for getting to LC
... and I think that cut-off date should be June 30
Summary of Action Items
[NEW] ACTION: Cameron to propose something for marking up
graphics with equivalent text [recorded in
[48]http://www.w3.org/2014/01/30-svg-minutes.html#action05]
[NEW] ACTION: Cameron to write spec text on transforming tspans
[recorded in
[49]http://www.w3.org/2014/01/30-svg-minutes.html#action08]
[NEW] ACTION: Chris to send Cameron an email with details on
how to send a liaison statement to MPEG about SVG in OpenType
[recorded in
[50]http://www.w3.org/2014/01/30-svg-minutes.html#action04]
[NEW] ACTION: Erik to add onbegin, onend, onrepeat to
SVGAnimationElement. [recorded in
[51]http://www.w3.org/2014/01/30-svg-minutes.html#action02]
[NEW] ACTION: erik to add ref to html5 for attr reflection
[recorded in
[52]http://www.w3.org/2014/01/30-svg-minutes.html#action07]
[NEW] ACTION: Erik to clarify <script> is not affected by
<switch> and will be run in there, but is still disallowed by
the content model. [recorded in
[53]http://www.w3.org/2014/01/30-svg-minutes.html#action01]
[NEW] ACTION: Erik to mention in SVG 2 that rootElement is
deprecated. [recorded in
[54]http://www.w3.org/2014/01/30-svg-minutes.html#action03]
[NEW] ACTION: Tav to think of text to clarify whether
transforms are taken into account with % objectBoundingBox
values in resource elements [recorded in
[55]http://www.w3.org/2014/01/30-svg-minutes.html#action06]
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [56]scribe.perl version
1.138 ([57]CVS log)
$Date: 2014-01-31 01:09:40 $
__________________________________________________________
[56] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[57] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11
Check for newer version at [58]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/
[58] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/Apirl/April/
Succeeded: s/something later/current work on defining zoom/
Succeeded: s/coloured/colored/
Succeeded: s/html fragments/svg fragments in html/
Succeeded: s/wirth/worth/
Succeeded: s/not/now/
Succeeded: s/pain/paint/
Succeeded: s/to tke/to take/
Succeeded: s/possibe/possible/
Found Scribe: Cameron
Found ScribeNick: heycam
Found ScribeNick: chrisl
Found ScribeNick: birtles
Found Scribe: Brian
Scribes: Cameron, Brian
ScribeNicks: heycam, chrisl, birtles
Default Present: +1.206.675.aaaa, nikos
Present: +1.206.675.aaaa nikos
WARNING: Fewer than 3 people found for Present list!
Agenda: [59]https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2014/Age
nda
Got date from IRC log name: 30 Jan 2014
Guessing minutes URL: [60]http://www.w3.org/2014/01/30-svg-minutes.html
People with action items: cameron chris erik tav
[59] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2014/Agenda
[60] http://www.w3.org/2014/01/30-svg-minutes.html
[End of [61]scribe.perl diagnostic output]
[61] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Received on Friday, 31 January 2014 01:14:19 UTC