gorilla/css

Package gorilla/css is a CSS3 tokenizer.

css's Issues

_double_quote vs _single_quote

Double quotes are more common and idiomatic in both CSS and HTML, single quotes are more common and idiomatic in JS. This is the same reason that JSX has double quotes, despite JS having single quotes: the similarity to HTML implies using similar quote styles. CSS → SASS is no different.

Am I correct at this?? @garyburd

Tokenizer works incorrectly when parsing CSS without line breaks

The tokenizer seems to work for pretty printed CSS, but it has trouble picking up closing brackets for CSS without line breaks. Because it does not identify the line breaks, it produces a string token with lots of CSS insider of it. All that CSS is inaccessible.

Implications of this bug

Much of the CSS found in the wild has removed line breaks to save space. This bug prevents much of the CSS found on the web from being parsed properly.

Steps to reproduce

the following valid CSS parses correctly when pretty printed, and incorrectly when it is not pretty printed. Inspect the tokens produced for the pretty printed version and the non- pretty printed version.

#sw_tfbb,#id_d{display:none}.sw_pref{border-style:solid;border-width:7px 0 7px 10px;vertical-align:bottom}#b_tween{margin-top:-28px}#b_tween>span{line-height:30px}#b_tween .ftrH{line-height:30px;height:30px}input{font:inherit;font-size:100%}.b_searchboxForm{font:18px/normal 'Segoe UI',Arial,Helvetica,Sans-Serif}.b_beta{font:11px/normal Arial,Helvetica,Sans-Serif}.b_scopebar,.id_button{line-height:30px}.sa_ec{font:13px Arial,Helvetica,Sans-Serif}#sa_ul .sa_hd{font-size:11px;line-height:16px}#sw_as strong{font-family:'Segoe UI Semibold',Arial,Helvetica,Sans-Serif}#id_h{background-color:transparent!important;position:relativ e!important;float:right;height:35px!important;width:280px!important}.sw_pref{margin:0 15px 3px 0}#id_d{left:auto;right:26px;top:35px!important}.id_avatar{vertical-align:middle;margin:10px 0 10px 10px}

Perform all preprocessing as per the spec.

The spec indicates there are more preprocessing rules to implement. Namely, in addition to replacing pairs of CRLF, also replace CR (by itself) and FF (by itself) with LF. As well as replace NULL code with the replacement char.

Parser does not properly emit bad-string tokens

The "consume an at-rule" algorithm says that the following should result in an at-rule with a prelude of title 56 56 Who's this d****e? and no block, but instead enters an "unclosed q" error state.

https://www.w3.org/TR/css-syntax-3/#consume-an-at-rule

Real world example: https://mspfa.com/?s=21504&p=2 (added to a <style> element dynamically, CSS is in the .y field obtained from POST mspfa.com do=story&s=21504)

@mspfa title 1 1 Fanventure START!!;
/*                   vvv Unmatched quote */
@mspfa title 56 56 Who's this d****e?; @mspfa title 62 64 ???;
@mspfa title 131 131 Troll time. @mspfa title 194 194 What is this, Rick and Morty eyes?;
/* ... custom at-rules continue ... */

.p436 #content div {
    background-color: #FFFFFF;
    border: 4px solid #009933;
    padding: 15px 25px;
    box-shadow: 4px 4px #005500;
}

/* ... normal CSS rules continue ... */

update for the recent css spec change?

i think you use the version which dated from 2003.

http://www.w3.org/TR/2003/WD-css3-syntax-20030813/

Well, a lot happen in a decade.

Doesn't support escaped code points?

The "consume an escaped code point" rule doesn't appear to be implemented?