Re: Prism WPD plugin ‹ Telling HTML and XML (SVG, MathML etc) apart

I love, love, love the context linking of the properties back to WPD! Very
cool idea! I agree that these are the type of offerings that will keep
people driving back to WPD.

Greg


On Sat, May 18, 2013 at 7:49 AM, Julee Burdekin <jburdeki@adobe.com> wrote:

>  Even cooler! Thanks, Lea! J
>
>
> Sent from my "Smartphone" -- go figure...
>
>
> ----- Reply message -----
> From: "Lea Verou" <lea@w3.org>
> To: "Julee Burdekin" <jburdeki@adobe.com>
> Cc: "public-webplatform@w3.org" <public-webplatform@w3.org>, "Doug
> Schepers" <schepers@w3.org>
> Subject: Prism WPD plugin ‹ Telling HTML and XML (SVG, MathML etc) apart
> Date: Sat, May 18, 2013 6:46 AM
>
>
>
> Hi Julee,
>
>  See inline answers.
>
>  On May 13, 2013, at 21:50, Julee Burdekin <jburdeki@adobe.com> wrote:
>
>   Lea:
>
>  This is sooo cool. But I'm not sure what the offering is and what the
> interface is. Do I have this right? prismjs is syntax highlighting with a
> keyword linker plugin?
>
> Exactly.
>
>   Will the users of code.webplatform.org have do anything or is the
> keyword linker plugin something you plug in to code.webplatform.org?
>
> We will plug it into code.webplatform.org as well, but the main idea is
> something much bigger. Something that won't just be used in WPD Code or WPD
> code examples, but also in other websites that use Prism (and there are
> many, even big ones like Smashing Magazine or A List Apart) to promote WPD
> by adding value for their users. Win-win :)
>
>  Cheers,
> Lea
>
>
>  Thanks!
>
>  Julee
>  ----------------------------
> julee@adobe.com
> @adobejulee
>
>   From: Lea Verou <lea@w3.org>
> Date: Saturday, May 11, 2013 3:24 PM
> To: "public-webplatform@w3.org" <public-webplatform@w3.org>
> Cc: Doug Schepers <schepers@w3.org>
> Subject: Re: Prism WPD plugin — Telling HTML and XML (SVG, MathML etc)
> apart
> Resent-From: <public-webplatform@w3.org>
> Resent-Date: Saturday, May 11, 2013 3:24 PM
>
>   Here’s a first alpha version: http://prismjs.com/plugins/wpd/
>
>  It’s still unpublished in the plugin directory, as I wanted to get some
> feedback first. The tokens should be properly linked. Their styling is too
> obvious at this point, to spot potential mistakes. Before publishing, I
> will make the underline on hover only.
>
>  Things that are linked:
>
>  CSS
> - properties
> - atrules
> - pseudo-classes
> - pseudo-elements
>
>  Markup
> - tags
> - attributes
>
>  What else should I add? Please note that it should be easy to
> programmatically detect, e.g. CSS values like <length> would require lots
> of special casing.
>
>  Distinguishing between markup types proved out to be even harder than
> the solution I outlined in the previous message: Several (not few) elements
> did not correspond to specific interfaces in some browser, so I had to
> cache them in the script. Also, no browser seems to provide interface names
> for MathML elements, so I hacked around it by caching the HTML+SVG elements
> that start with "m" and having all others considered MathML.
>
>  Any feedback is very welcome.
>
>  Lea Verou
>  W3C developer relations
> http://w3.org/people/all#lea ? http://lea.verou.me ? @leaverou
>
>
>
>
>
>
>  On May 10, 2013, at 22:12, Lea Verou <lea@w3.org> wrote:
>
>  The problem
> =============
> As you might know, I’m writing a Prism [1] plugin that converts some
> tokens [3] into links to WPD documentation, both for our use and for
> developers in general, to promote WPD. A conundrum I ran into was how to do
> that for HTML and XML languages such as SVG and MathML. Prism currently
> uses the same language definition for both HTML and XML variants
> ("markup"), so it was hard for the plugin to decide where to link tokens
> found in "markup" contexts.
>
>  Solution #1
> ===========
> We chatted about this with Doug last week and we decided on using the WPD
> API to fetch a list of tags for HTML, SVG and MathML, so that Prism could
> use those to decide where those tokens [3] would link to. However, when I
> investigated this idea (thanks fr0zenice for helping with the API!), I
> encountered a number of issues. Since plugins hook into Prism’s main code,
> there is no way for a plugin to delay Prism execution (e.g. until an async
> request finishes). Therefore, the API requests would need to happen
> synchronously. This is a bad practice and could cause significant delays,
> making the plugin less appealing to authors. So, this solution is not
> feasible after all.
>
>  Note that we could always make an extended version of the plugin in the
> future, which makes API requests when somebody hovers over these tokens
> showing a tooltip or something, which would fetch the API info just-in-time
> instead of when the page loads.
>
>  Solution #2
> ===========
> The idea I’m probably going with (unless somebody has something better to
> suggest, which is why I'm writing this email) is to defer element
> recognition to the browser. Every known element (with very few exceptions,
> which could be special cased) corresponds to a specific interface, e.g.
> HTMLInputElement or SVGCircleElement. There is a way to get this interface
> name through JavaScript [2]. Unknown elements on the other hand resolve to
> different interface names, such as HTMLUnknownElement or HTMLElement or
> Element, depending on the browser. I’ve verified this is true for both
> Trident (IE10), WebKit and Gecko.
> The main issue I see with this solution is that elements that are not
> supported by the current browser would not be linked. That's unfortunate,
> but I don't think it's a blocker.
>
>  Hope it all makes sense, I tried to describe it in as much detail as
> possible. Any feedback and/or advice is welcome!
>
>  [1]: http://prismjs.com
> [2]: e.g. try document.createElementNS('http://www.w3.org/2000/svg',
> 'circle').toString()
> [3] tokens in this context are the parts of the code that get highlighted,
> e.g. "tag", "attribute", "property" etc.
>
>  Lea Verou
>  W3C developer relations
> http://w3.org/people/all#lea ? http://lea.verou.me ? @leaverou
>
>
>
>
>
>
>
>
>


-- 
Greg Whitworth