[Ur] Thoughts on <meta> tags in Ur/Web?

[Adam Chlipala]

I was thinking of just leaving 'http-equiv' out of the attribute list!  
Is there a reason to prefer <meta http-equiv="X-UA-Compatible"> over 
setting that header in the HTTP response?

The character set is already set to UTF-8 in the HTTP response, so I 
think the first <meta> below is not important.

The viewport example is the one I'm already aware of.  It's a bit lame 
that the same can't be done with CSS or an HTTP response header!

On 04/15/2016 08:24 PM, foldr at tutanota.com wrote:
> The most obvious choice is whitelisting, at least for for http-equiv, 
> because the specification is relatively complex.
> https://www.w3.org/TR/html401/struct/global.html#edef-META
>
> Whitelisting for name attribute might be less usable, but I do not 
> know whether it is important to add keywords for search engines these 
> days. Probably not.
> https://www.w3.org/TR/html401/appendix/notes.html#recs
>
> Personally I am interested to see support for the use cases below.
>     <meta charset="utf-8"/>
>     <meta http-equiv="X-UA-Compatible" content="IE=edge"/>
>     <meta name="viewport" content="width=device-width, 
> initial-scale=1.0"/>
>
> At the moment I just define meta as
> val meta : unit -> tag [Nam = string, Content = string, Http_equiv = 
> string, Charset = string] head [] [] []
>
>
> 16. Apr 2016 10:35 by adamc at csail.mit.edu <mailto:adamc at csail.mit.edu>:
>
>     Someone recently requested a nice way to include a <meta
>     name="viewport" content="..."> tag in Ur/Web. It doesn't seem safe
>     to expose <meta> in its most general form, with type [string] for
>     each attribute, since it seems like browsers could interpret those
>     strings in quite arbitrary ways, which goes against Ur/Web's
>     philosophy about implicit interpretation of strings as programs.
>
>     Are there any opinions, then, on the right way to expose this tag?
>
>     My first thought is to add an application-level whitelist of which
>     <meta> names are allowed, just as with HTTP header names. Then the
>     'content' attribute could be exposed as [string], while the 'name'
>     attribute would have an abstract type of allowable names. The
>     programmer would need to be careful not to whitelist names that
>     can lead to mayhem.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.impredicative.com/pipermail/ur/attachments/20160416/2710855c/attachment.html>